What do you mean by thread safe collections?  Should only one thread at a
time be able to perform #do: on a collection?  Obviously we want to make
sure that only one #add: or #remove: can be done at a time, but you should
probably prevent #add: and #remove: when some other thread is running
#do:.   So, this will be the readers/writers problem.  You should make a
ReaderWriterLock class with methods #read: aBlock and #write: aBlock that
are similar to Semaphore's #critical: method.  Then you can make a subclass
of Set called ThreadSafeSet with an instance variable rwLock that is a
ReaderWriterLock and methods like

add: anElement
wrLock write: [^super add: anElement]

do: aBlock
wrLock read: [^super do: aBlock]

It hardly seems worthwhile using traits in a case like this.  All the code
will be very simple.  The hard part will be deciding what the granularity of
locks should be, and how inheritance interacts with it.  Traits will not
make this easier.  When it comes to concurrency, inheritance is the problem,
not the solution.

To answer your original question, it is a very bad idea to make every
collection thread safe.  Making them thread safe will make them slow and
complicated.  In general, multithreading makes things mroe complicated, and
if you aren't careful it can make things slower, too.

Keeps threads as isolated from each other as possible.  Have them interact
though a narrow interface.  It is fine to custom-design these classes, or
else use a few classes that are designed for communication between threads,
such as SharedQueue or Promise.  But don't try to make most classes
threadsafe, since that contradicts the prime imperative of keeping most
classes simple.

-Ralph Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080424/73b6df6a/attachment.htm