Re: Question About Thread Safety

In message <[email protected]>, K
evin Stussman writes:
>"All the state affecting methods are synchronized to avoid the maintenance
>of explicit locks in multithreaded programs. This philosophy differs from
>the org.apache.oro.text.regex package, where you are expected to either
>maintain explicit locks, or more preferably create separate compiler and
>matcher instances for each thread."
>This is a little vague to me. Does this mean we can share an object like
>Perl5Util or no? Our tests seem to say no. On the surface, it looks like

The documentation should elaborate more.  Any state altering
method is guaranteed not to interfere with the execution of another
state altering method.  So concurrent calls to match(), substitute(),
and split() will all generate correct results.  But you're talking about
calling group() after calling match(), so you need to synchronize your
critical section explicitly.

>.matches() from other threads are getting mixed up in .group() function
>across threads....(i.e. the match result from one thread gets put into the
>group call from another). This is classic non-thread safety.

The use of the term "thread safe" with an overly scoped definition is
a pet peeve of mine, but perhaps I'm being too academic and inappropriately
rejecting what may have become the mainstream interpretation of the term.
The concurrent execution of any two methods will never place a Perl5Util
instance into an inconsistent state.  Therefore it is thread safe.  The
org.apache.oro.text.regex package is also thread safe in the same way that
the SGI STL is thread safe.  It guarantees correctness of simultaneous
access to distinct objects and simultaneous read access to shared objects,
but requires explicit synchronization for a concurrent write.

Now, you've presented a particular use case that indicates a desire for
storing match results as separate values in thread local storage.  I
don't have a strong opinion about this, but I tend to prefer offloading
per-thread instance tracking to the client because it tends to be an
application-specific requirement.  For example, a class with mostly thread
local state would be better served as having no thread local state and
allowing the client of the class to decide whether it needs a separate
instance of the class per thread (e.g., the way you do with Perl5Matcher).
That said, the class library should  evolve to do whatever its users
require.  Does anybody else want this?  The other alternative is to make
the documentation more explicit because you've shown it is deficient.

If people want the feature, I would suggest we make two versions of the
Perl5Util class.  One without any synchronization at all and a subclass
that does the per-thread result management and method synchronization.  As
long as the setting of the result state is done through a method that can
be overridden in the subclass, the subclass just has to override that
method in addition to wrapping the parent methods with synchronized calls.
The subclass should be called Perl5Util so as not to break existing
code that relies on the mutual exclusion of state altering methods.  This
is exactly the sort of thing that would be cleaner to implement with
AspectJ and a dynamic aspect weaver, but I digress.

daniel