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<br>
<br>add: anElement<br>wrLock write: [^super add: anElement]<br><br>do: aBlock<br>wrLock read: [^super do: aBlock]<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>-Ralph Johnson<br>