Java thread API

First let me say that I am quite comfortable with the 5005 thread API and
have no serious objection to retaining it.  The model where threads share
everything by default and use locks around critical sections is the
traditional model and the one I'm most comfortable with.

One thing I have found a bit cumbersome to do under the current thread API
is to examine whether a variable or a method is already locked before I
attempt to lock it (or call it in the case of a method).  It is sometimes
useful to know if a variable is already locked so that I don't block while
attempting to lock it.  In some cases I might prefer to do other tasks if
I know that a certain variable is already locked.  Think of it as an
atomic test-and-lock() function that doesn't block but returns success or
failure.  Anyway, I just wanted to mention that.

Now to the real point of this message.  Has the Java thread
synchronization API been considered for use in Perl?  I've looked thru the
Perl archives a bit and not found any discussion of it.  I apologize in
advance to all who are well aware of it and think it stinks.

In Java, code segments and variables that need to be accessible from
multiple threads are marked or tagged with a "synchronize" modifier (much
like the explicit "shared" modifier that has been proposed in the ithreads
model).  The difference is that once code segments and variables are
tagged in this way, it becomes the interpreter's responsibility to ensure
that at least one, but no more than one, thread can access this tagged
code.  The advantage is that, from that point on, the programmer does not
concern themself with explicitly calling lock().  The interpreter already
knows that the tagged entity needs to be kept thread safe and supplies the
locks internally.  This helps to avoid deadlocks that can occur when
programmers have to supply their own lock() calls explicitly.

Consider a threaded server example with one thread per client.  Suppose
there is a client count variable that each client needs access to.  In
perl the variable might be declared as follows:

my $client_count (synchronize);

At this point the $client_count variable is tagged as shared between all
threads (like the ithreads model), but from here on the programmer need
never concern themself with explicitly lock()'ing the variable each time
it is to be accessed.  The interpreter controls thread access internally
and supplies whatever locking mechanism that fits the environment so that
only one thread has access at any point in time.  This frees the
programmer from having to think about manually controlling thread flow.

The goal in "thread safety" is not to give the programmer explicit control
over thread flow.  The goal in thread safety is simply to keep shared
resources from getting corrupted by simultaneous thread access.  The
interpreter can handle this task as long as the programmer specified where
thread safety is required.  The interpreter can also do a better job of
guaranteeing that at least one thread has access (i.e. no deadlocking).

I believe Java also allows disconnected (but related) critical code
segments to be synchronized in named sets.  In Perl this might look like:

sub my_sub1 (synchronized "id5") {
  ...critical code...
} 

sub my_sub2 (synchronized "id5") {
  ...critical code...
}

sub my_sub3 (synchronized "id6") {
  ...unrelated critical code...
}

The code above would allow only one thread to be in either my_sub1 or
my_sub2 because they share the same synchronization identifier "id5".  But
another thread could be in my_sub3 since it has a different identifier.

Dan Sugalski has mentioned the desire to have a thread model that allows
the interpreter to avoid nasties like thread deadlock without relying so
heavily on the programmer.  The approach used by Java is very intuitive
and very high level.  It doesn't deal with explicit thread flow control,
it simply deals with requests to "make this resource thread safe".  This
scheme does not distinguish between read access and write access to a
shared resource.  Which is well suited to Perl's case, since some read
operations can internally result in a write operation (such as implicit
casting of a variable between string and integer).

If I can ask the interpreter to keep a variable (or code segment) thread
safe, the only other thing I might be interested in (as far as API) is a
way of knowing whether a thread is already using the shared resource I
want access to.  This allows the programmer to avoid blocking waiting for
a resource to become available.  Of course it would also be nice to have a
way to clean up (kill) all threads (which may be blocking on IO) as part
of a global shutdown.

Again, I apologize if the Java model has already been discussed/rejected,
but I have used it and it is quite intuitive and comfortable.  I imagine
it also has the benefit of shielding the Perl programmer from
implementation issues, which might contribute to platform portability.

Thanks.

• thread API by jasho
• Java thread API by jasho