On 26.12.2008 10:43, Robert Dober wrote:
>  I would very much welcome a set of guaranteed-thread-safe wrapper
>> collections folks could use if they're concerned about concurrency, since it
>> would be unreasonable to penalize all code with locking. For now, learn and
>> love Mutex, or don't share collections across threads.
> 
> That sounds like a fun job. The issue goes well with a question which
> burns on the top of my tongue:
> How to test thread issues? I do not have any experience in this field
> but consider it somehow critical before "promising" functional thread
> safe wrappers.

This is tricky.  There are few things I'd like to say to this: first, 
there is an easy way to provide _basic_ thread safety by wrapping all 
method calls in a synchronized block - for this even a 
SynchronizedDelegator would be sufficient which could be used for _all_ 
classes - not just collections.  In this case, because of the way the 
wrapping is done there is no need to test thread safety because - as 
long as the delegator ensures that all methods are wrapped in this way 
there is no chance of corrupting internal state.

But, in the general case thread safety cannot be achieved on the class 
level.  My typical example is this

if hash.contains_key? k
   dat = hash[k]
else
   dat = create_dat(k)
   hash[k] = dat
end

The basic property of this bit of code which makes it impossible to 
ensure thread safety on level of class Hash is that there are two 
methods invoked on the same instance and there must not be any state 
change between them because then you either end up with garbage (nil) in 
"dat" or you invoke create_dat(k) more than once per key value and this 
leads to different threads having a different idea of what hash[k] is.

So in this case you need a lock around the _complete_ block of code. 
(Note, the method level lock would work if using a Hash with a default 
block, but this solves only a small portion of the cases.)  This is also 
the reason why a general per method locking is only of limited use.  It 
only ensures consistency of the internal state of an object but can 
never ensure overall concurrency correctness of an application.

Testing thread safety is difficult to impossible for several reasons. 
One of the reasons is that for proper control of the test case you would 
need to ensure exact timing of thread execution.  While you could do 
that I have never seen people actually doing this - maybe because this 
will make test suites run much slower.  Another reason is that you 
vastly depend on the underlying machine (i.e. hardware, OS and VM).  I 
have seen Java programs break as soon as they were executed on a multi 
core machine with more than n cores.

Things aren't made easier by the fact that - concluding from postings I 
see on comp.lang.java.* newsgroups for example - few people seem to have 
a thorough understanding of concurrency and all the issues involved. 
Another item on the "makes it hard" list is the fact that most OO and 
procedural languages only have a very basic toolkit for concurrency 
control; while Java started out pretty good with built in "synchronized" 
it took until version 5 that they incorporated Doug Lea's concurrency 
utilities into the language's standard library and also into the EJB spec.

It's different in other programming languages: functional languages are 
by definition thread safe because they are free of side effects.  (At 
least in theory. :-))  Also, other languages built for concurrent 
applications which have a different programming model (e.g. Occam) of 
course have much better support for concurrency.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end