Re: Synchronized*

On May 26, 2009, at 11:37 PM, Seth Tisue wrote:

> David> synchronizing all the methods is not a good way to add thread
> David> safety to a class anyway. If this is the best one can do for a
> David> class then it's uniformly better to declare it to not be
> David> threadsafe and manage synchronization externally.
>
> +1,000,000

But isn't this exactly what they do?

iulian

>

I think SynchronizedMaps are very useful form a client perspective. I
needed them myself in the Scala Eclipse IDE. Workarounds from clients
are probably worse than the functionality provided by SynchronizedMap.
Sure, you have to be careful when extending the collection classes,
and also when creating your own maps. But these are the rare cases.
The most common case is that you want to take a standard map
implementation off the shelf and make it synchronized.
So, for all their shortcomings I believe that SynchronizedMap/Set are
essential ingredients of a collection library.

Cheers

I should mention that the problems with SynchronizedMap could also be
interpreyted as a shortcoming of the language. What you want is a
form of quantification, that you can mixin a feature to all methods of
a class or trait automatically, or by a wildcard. AOP can do that, of
course, but it comes with lots of other features entangled with it.

Cheers