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

synchronized/wait/notify on AnyRef

6 replies
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
One of the many mistakes of Java, IMO, was to make every object a monitor, i.e. the ability to be used in a synchronized block and with wait/notify methods. Scala seems to have repeated this, by providing synchronized/wait/notify methods on AnyRef.

Why wasn't this put in a trait instead?

Nils
Sciss
Joined: 2008-12-17,
User offline. Last seen 28 weeks 5 days ago.
Re: synchronized/wait/notify on AnyRef

just curious: why you think that was a mistake in java?

Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:

> One of the many mistakes of Java, IMO, was to make every object a
> monitor, i.e. the ability to be used in a synchronized block and
> with wait/notify methods. Scala seems to have repeated this, by
> providing synchronized/wait/notify methods on AnyRef.
>
> Why wasn't this put in a trait instead?
>
> Nils

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: synchronized/wait/notify on AnyRef
I would say Java compatibility and to a certain degree consistency.  All Scala objects on the JVM ultimately derive from java.lang.Object, which for better or for worse has the capabilities.  I'm sure the compiler could to tricks to hide them, but it seems like it would be far more trouble than it's worth.

On Wed, Feb 11, 2009 at 8:42 AM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
One of the many mistakes of Java, IMO, was to make every object a monitor, i.e. the ability to be used in a synchronized block and with wait/notify methods. Scala seems to have repeated this, by providing synchronized/wait/notify methods on AnyRef.

Why wasn't this put in a trait instead?

Nils



--
http://erikengbrecht.blogspot.com/
nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: synchronized/wait/notify on AnyRef
On Wed, Feb 11, 2009 at 7:50 AM, Sciss <contact [at] sciss [dot] de> wrote:
just curious: why you think that was a mistake in java?

Because not every object has this need.
DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: synchronized/wait/notify on AnyRef

On 2/11/09, Nils Kilden-Pedersen wrote:
> One of the many mistakes of Java, IMO, was to make every object a monitor,
> i.e. the ability to be used in a synchronized block and with wait/notify
> methods. Scala seems to have repeated this, by providing
> synchronized/wait/notify methods on AnyRef.
>
> Why wasn't this put in a trait instead?

Well, because scala.AnyRef == java.lang.Object, so those methods are
supported by all AnyRefs rather than provided by a trait.

Dave Griffith
Joined: 2009-01-14,
User offline. Last seen 42 years 45 weeks ago.
Re: synchronized/wait/notify on AnyRef

In decreasing order of importance

1) It lets developers who don't understand concurrency convince themselves
that they do.
2) It is incredibly easy to get locks on the wrong object, resulting in
subtle and intermittent bugs
3) It inherently breaks encapsulation.
4) It prevents any Java object from being truly functional.
5) It increases the size of just about every object by requiring a pointer
to a monitor pool (and yes, there are environments where that sort of thing
really matters).

While it probably won't be (for Java compatibility reasons), I would love to
see synchronized/wait/notify moved to a trait.

Sciss-3 wrote:
>
> just curious: why you think that was a mistake in java?
>
> Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:
>
>> One of the many mistakes of Java, IMO, was to make every object a
>> monitor, i.e. the ability to be used in a synchronized block and
>> with wait/notify methods. Scala seems to have repeated this, by
>> providing synchronized/wait/notify methods on AnyRef.
>>
>> Why wasn't this put in a trait instead?
>>
>> Nils
>
>
>

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: synchronized/wait/notify on AnyRef
Because you should carefully control what objects you lock on, otherwise you're likely to cause deadlock.  A Lock type instead of Object having this would be good.

It's best not to do pessimistic locking, but if you do, do it on objects you don't give out references to.

As for Scala repeating it, not doing so would be difficult wouldn't it, as Object is the root of the class hierarchy on the JVM.  You're free to implement lock(lock: Lock)(whileLocked: => Unit) and ignore the Java drainbammage.

2009/2/11 Sciss <contact [at] sciss [dot] de>
just curious: why you think that was a mistake in java?

Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:

One of the many mistakes of Java, IMO, was to make every object a monitor, i.e. the ability to be used in a synchronized block and with wait/notify methods. Scala seems to have repeated this, by providing synchronized/wait/notify methods on AnyRef.

Why wasn't this put in a trait instead?

Nils


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