On Mon, 05 Jan 2004 12:58, Nigel Sandever wrote;
> Everything else, were my attempts at solving the requirements of
> synchronisation that this would require, whilst minimising the
> cost of that synchronisation, by avoiding the need for a mutex on
> every shared entity, and the costs of attempting to aquire a mutex
> except when two SHARED THREADS attempted concurrent access to a
> shared entity.
This paragraph sounds like you're trying to solve an intractable problem.
Try posting some psuedocode to explain what you mean.
But it has given me an idea that could minimise the number of locks,
ie not require a mutex on each PMC, just each shared PMC. 10 points
to the person who finds a flaw in this approach :)
Each object you share, could create a new (virtual) shared memory
segment with its own semaphore. This virtual memory segment is
considered its own COW domain (ie, its own thread to the GC);
references inserted back to non-shared memory will pull the
structures into that virtual COW thread.
Access to the entire structure is controlled via a multiple
reader/single writer lock (close to what a semaphore is IIRC); locks
for a thread are released when references to places inside the
shared segment are no longer anywhere in any @_ on the locking
thread's call stack, or in use by any opcode (is that good enough?),
and are acquired for writing when anything needs to be changed.
Virtual shared memory segments can then easily be cleaned up by
normal GC.
The major problem I can see is that upgrading a lock from reading to
writing can't work if there are concurrent writes (and the read lock
to be upgraded cannot sensibly be released). But that should be OK,
since operation signatures will mark variables that need changing as
read-write as early as possible.
For example, in this sort of code (sorry for P5 code);
sub changer {
my $shared_object = shift;
$shared_object->{bar} = "baz";
}
A read lock to the segment \$shared_object is in is acquired, then
released when it is `shifted' off. As the next instruction has a
writable lvalue, it acquires a write lock. But this code:
sub changer {
my $shared_object = shift;
$shared_object->{bar} = &somefunc();
}
Will hold the write lock on $shared_object open until &somefunc
runs.
My 2¢ :). This discussion will certainly reach a dollar soon ;).
--
Sam Vilain, [EMAIL PROTECTED]
Start every day with a smile and get it over with.
W C FIELDS
