On Thu, Aug 21, 2003 at 03:31:42PM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:

> > I'm not sure if a simple read/write split also helps PMCs shared across
> > threads. Maybe sharing between threads is a whole new can of worms that we
> > should leave untouched for now.
> 
> When a PMC is shared it is either ro or rw - in all threads. I don't see
> a problem here.

I don't see a problem but I do see a possible optimisation.
I can't remember if you were still in the p5p meeting in Paris when Arthur
explained Sarathy/his idea about doing copy on write of whole scalars in
perl5 for ithreads.

Basically the idea was that when a new thread is created, scalars aren't
copied immediately. However, they aren't locked - they are treated as
read only (with a reference count, boo hiss, of interested threads)
If a thread finds that it needs to modify something (with a reference count
>= 2) then it does lock that scalar (and checks again)
At that point it makes its own copy of the scalar, leaving the original
intact (untouched) for the other threads to keep on seeing.
(Obviously when it has made the copy it then unlocks the other)
The last thread inherits the original.

The beauty is that no shared scalar is ever written.

I think that something like this could also work in parrot - you replace the
write vtable ops with the lock/check/copy versions, but leave the read ops
intact. When you do the copy and it's now an unshared PMC you revert the
write vtable ops to the usual fast set. Hence why I made a connection
between split read/write ops and threading.

Nicholas Clark

Reply via email to