Patrick Logan wrote:
> 
>     Gemstone's RC classes might be a good thing to study in this
>     regard...
> 
> The RC (Reduced Conflict) collections in Gemstone Smalltalk are *not*
> thread safe. They assume a consistent view within a Smalltalk image,
> and the Gemstone "image" is not multi-threaded (well, it's not
> asynchronously pre-emptive). What is an RC class? Each specific RC
> class defines special conditions under which concurrent transactions
> to the persistent storage will succeed even though there may be
> lower-level "write/write" conflicts. For example, concurrent
> transactions adding objects to the same Bag each "write" the Bag, but
> should succeed WRT Bag semantics.
> 
>     Also java has a bit to offer as well. (and by extension,
>     Gemstone/J would be worth looking at)...
> 
> Well, Java has the "synchronized" keyword for monitoring access to
> shared data. Applications sometimes use other mechanisms such as
> mutexes because of the limitations of monitors.

I guess the synchronized keyword could be emulated quite easily in
Smalltalk
using blocks. As far as I can remember  there exists some free
"synchornize"
package for smalltalk. 

> 
>     Also, isn't the whole single-threaded vs multi-threaded issue
>     parallel to java's green vs native threads?
> 
> Part of the issue is thread-safe methods. A method that is not aware
> of other threads may stomp all over the same data as the other thread.
> 

So we should support multithreaded programming better. 
I think we can do better, "even" better then Java ...

Markus

-- 
Markus Kohler  mailto:markus_kohler at hp.com