What do you mean by thread safe collections?&nbsp; Should only one thread at a time be able to perform #do: on a collection?&nbsp; 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:.&nbsp;&nbsp; So, this will be the readers/writers problem.&nbsp; You should make a ReaderWriterLock class with methods #read: aBlock and #write: aBlock that are similar to Semaphore&#39;s #critical: method.&nbsp; 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.&nbsp; All the code will be very simple.&nbsp; The hard part will be deciding what the granularity of locks should be, and how inheritance interacts with it.&nbsp; Traits will not make this easier.&nbsp; 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.&nbsp; Making them thread safe will make them slow and complicated.&nbsp; In general, multithreading makes things mroe complicated, and if you aren&#39;t careful it can make things slower, too.<br>
<br>Keeps threads as isolated from each other as possible.&nbsp; Have them interact though a narrow interface.&nbsp; 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.&nbsp; But don&#39;t try to make most classes threadsafe, since that contradicts the prime imperative of keeping most classes simple.<br>
<br>-Ralph Johnson<br>