This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Synchronized*

1 reply
DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.

Hi,

I was talking to paul about this in #scala and basically came to the
conclusion that SynchronizedMap, SynchronizedBuffer, etc. are actually
a terrible idea. I would like to advocate their removal in 2.8 (or at
least their extreme deprecation, but given that they're broken already
it seems a shame to put a fair bit of effort into fixing them and then
deprecating). Allow me to enumerate the reasons:

* First off, they create a code maintenance nightmare. You have to
make sure they override basically all the methods in their parent
trait, and there's no static checking of this fact. This could be
gotten around if they were really super useful, but it makes their
inclusion very much not a low cost proposition.
* It's of limited utility in that it fails to cover synchronization in
a lot of cases even once you've gotten past that. Given "class MyMap
extends mutable.HashMap[Stuff, Stuff] with SynchronizedMap { ... }",
I need to worry about synchronization of all methods I add or override
in this class. Further the apparent safet of the SynchronizedMap makes
it easy to forget to do this.
* It fails to compose with other traits in dangerous ways. Consider
the semantics of new mutable.Map with ObservableMap with
SynchronizedMap vs. new mutable.Map with ObservableMap with
SynchronizedMap. The first is safe (ish. subscription still isn't
threadsafe, but notification is), the second is a bug waiting to
happen.
* synchronizing all the methods is not a good way to add thread safety
to a class anyway. If this is the best one can do for a class then
it's uniformly better to declare it to not be threadsafe and manage
synchronization externally.

All told I think they don't really do a good job of solving the
problem they're trying to solve, and instead seem a source of worrying
concurrency bugs. This doesn't seem to be something to encourage.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: Synchronized*
+1

As a side note, I think we might want to watch for some anti-patterns emerging around the usage of mixins.

On Tue, May 26, 2009 at 5:34 PM, David MacIver <david.maciver@gmail.com> wrote:
Hi,

I was talking to paul about this in #scala and basically came to the
conclusion that SynchronizedMap, SynchronizedBuffer, etc. are actually
a terrible idea. I would like to advocate their removal in 2.8 (or at
least their extreme deprecation, but given that they're broken already
it seems a shame to put a fair bit of effort into fixing them and then
deprecating). Allow me to enumerate the reasons:

* First off, they create a code maintenance nightmare. You have to
make sure they override basically all the methods in their parent
trait, and there's no static checking of this fact. This could be
gotten around if they were really super useful, but it makes their
inclusion very much not a low cost proposition.
* It's of limited utility in that it fails to cover synchronization in
a lot of cases even once you've gotten past that. Given "class MyMap
extends mutable.HashMap[Stuff, Stuff] with SynchronizedMap { ... }",
I need to worry about synchronization of all methods I add or override
in this class. Further the apparent safet of the SynchronizedMap makes
it easy to forget to do this.
* It fails to compose with other traits in dangerous ways. Consider
the semantics of new mutable.Map with ObservableMap with
SynchronizedMap vs. new mutable.Map with ObservableMap with
SynchronizedMap. The first is safe (ish. subscription still isn't
threadsafe, but notification is), the second is a bug waiting to
happen.
* synchronizing all the methods is not a good way to add thread safety
to a class anyway. If this is the best one can do for a class then
it's uniformly better to declare it to not be threadsafe and manage
synchronization externally.

All told I think they don't really do a good job of solving the
problem they're trying to solve, and instead seem a source of worrying
concurrency bugs. This doesn't seem to be something to encourage.



--
http://erikengbrecht.blogspot.com/

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland