Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:06 AM +0100 12/23/03, Leopold Toetsch wrote:
>>
>>Again, not only strings but all kind of containers using managed
>>resources suffer from that problem.
>>
>>All that seems to imply, that we need two locks for shared access: one
>>for protecting DOD/GC and a second for the PMC. Any container (including
>>PerlStrings) would have to aquire the first (interpreter-global) lock,
>>while a PerlNum only needs the second per PMC mutex. Ugly.
> Yeah, it all potentially gets nasty.
Thinking a bit further about that issue /me thinks that we need:
1) one spare interpreter holding the shared resources[1]
2) on resource shortage this interpreter does DOD/GC else it
does nothing[2]
3) to accomplish 2) in a save way, all threads having a shared resource
must be suspended.[3]
Rational:
Looking at e.g string.c (but that could be list.c or hash.c too), we
have code like this:
FLOATVAL
string_to_num(const STRING *s)
...
const char *start = s->strstart; // (1)
const char *end = start + s->bufused; // (2)
This function is used by PerlString::get_integer() or ::get_number -
that is a *read* access of a PMCs data. Now when this PerlString is
shared between different PMCs, there is a chance that between (1) and
(2) the copying collector moves strstart to a different place, *if* the
owning thread does a GC run at that time: "start" and "end" are out of
sync - boom. We have such code all over the place, I don't see any
chance to rewrite that in a way, so that a GC run in the background
wouldn't harm.
We could of course lock the owning interpreter for *all* accesses, but
that seems more expensive than above "solution".
[1] basically the arena_base only and some more bits
[2] It would wait on a condition. If any thread allocates shared
resources, the spare interpreter would wake up, check if there is a
shortage in resources, and if yes suspend threads and run DOD/GC.
Considering how DOD runs with shared PMCs work is still more fun.
[3] They can't be suspended inmidst of an arbitrary operation (and
pthread doesn't even provide suspending) so they would be sent a suspend
event so that they are in a safe state in the run-loop, or better in the
event-handler opcode, called from there.
leo
