Chaim Frenkel wrote:
> UG> i don't see how you can do atomic ops easily. assuming interpreter
> UG> threads as the model, an interpreter could run in the middle of another
> UG> and corrupt it. most perl ops do too much work for any easy way to make
> UG> them atomic without explicit locks/mutexes. leave the locking to the
> UG> coder and keep perl clean. in fact the whole concept of transactions in
> UG> perl makes me queasy. leave that to the RDBMS and their ilk.
>
> If this is true, then give up on threads.
>
> Perl will have to do atomic operations, if for no other reason than to
> keep from core dumping and maintaining sane states.
I don't see that this is necessarily true. The best suggestion I have
seen so far is to have each thread be effectively a separate instance of
the interpreter, with all variables being by default local to that
thread. If inter-thread communication is required it would be done via
special 'shareable' variables, which are appropriately protected to
ensure all operations on them are atomic, and that concurrent access
doesn't cause corruption. This avoids the locking penalty for 95% of
the cases where variables won't be shared.
Note however that it will *still* be necessary to provide primitive
locking operations, because code will inevitably require exclusive
access to more than one shared variable at the same time:
push(@shared_names, "fred");
$shared_name_count++;
Will need a lock around it for example.
Another good reason for having separate interpreter instances for each
thread is it will allow people to write non-threaded modules that can
still be safely used inside a threaded program. Let's not forget that
the overwhelming bulk of CPAN modules will probably never be threaded.
By loading the unthreaded module inside a 'wrapper' thread in the
program you can safely use an unthreaded module in a threaded program -
as far as the module is concerned, the fact that there are multiple
threads is invisible. This will however require that different threads
are allowed to have different optrees - perhaps some sort of 'copy on
write' semantic should be used so that optrees can be shared cheaply for
the cases where no changes are made to it.
Alan Burlison
