objects and thread safety...

[William Uther]

Hi all,

Is the construction of singleton objects supposed to be thread safe?

e.g:

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server
VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import scala.actors.Futures._
import scala.actors.Futures._

scala> class TestOuter {
| case object TestInner {
| println("Constructing new TestInner")
| }
| def get = TestInner
| }
defined class TestOuter

scala> val context = new TestOuter()
context: TestOuter = TestOuter@2a717ef5

scala> for (i <- 0 until 10) {
| future{Thread.sleep(1); println(context.get)}
| }

scala> Constructing new TestInner
TestInner
Constructing new TestInner
TestInner
TestInner
TestInner
TestInner
TestInner
TestInner
TestInner
TestInner
TestInner

Note that two TestInner's were constructed - one in each of the first
two threads (This test was on a dual core machine). Is this a bug, or
a defined-to-be-not-threadsafe behaviour?

Cheers,

Will :-}

[Paul Phillips]

On 3/1/11 4:06 AM, William Uther wrote:
> Hi all,
>
> Is the construction of singleton objects supposed to be thread safe?

Supposed to be, yes.

https://lampsvn.epfl.ch/trac/scala/ticket/1591
"Inner objects inside a class are not singletons"

[Tommaso Galleri]

This is a very basic thing and I am surprised it's still wrong in 2.8.1
(bug raised 2 years ago?).

Supposed to be, yes.

The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed, to persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS do not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, First Floor, Coronet House, Queen Street, Leeds, LS1 2TW

[Hubert Plociniczak]

On 03/01/2011 11:03 AM, Tommaso Galleri wrote:
> This is a very basic thing and I am surprised it's still wrong in 2.8.1
> (bug raised 2 years ago?).

The reason why it is not in 2.8.1 is because it would have broken binary
compatibility so I doubt you will see it on 2.8.x branch.
And believe me, it wasn't easy to fix that monster.

Thanks,
hubert

[Nils Kilden-Pedersen]

As somewhat of a tangent, is there any difference between using an inner object and a simple val?

E.g.:

class Foo {
  object Bar1 {
    def bar = println("Bar1")
  }
  val Bar2 = new {
    def bar = println("Bar2")

[Ken Scambler]

As far as I know, objects are lazily initialised, and cannot be overridden.  Not sure how a final lazy val differs though.

On 02/03/2011 11:50 PM, "Nils Kilden-Pedersen" <nil...@gmail.com> wrote:
> On Wed, Mar 2, 2011 at 12:02 AM, Ken Scambler <ken.sc...@gmail.com>wrote:

>
>> On 2 March 2011 00:40, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
>>
>>> As somewhat of a tangent, is there any difference between using an inner
>>> object and a simple val?
>>>

>>> In 2.8.0: (apologies for using a crusty old release):
>>
>
> Yes, I understand there will be bytecode differences :-) I was wondering if
> there was any semantic difference?
>
>
>>
>> >javap -private Foo
>> public class Foo extends java.lang.Object implements scala.ScalaObject{
>> private Foo$Bar1$ Bar1$module;
>> private final java.lang.Object Bar2;
>> public Foo();
>> public java.lang.Object Bar2();
>> public final Foo$Bar1$ Bar1();
>> }
>>
>> >javap -private Foo$$anon$1
>>
>> public final class Foo$$anon$1 extends java.lang.Object{
>> public Foo$$anon$1(Foo);
>> public void bar();
>> }
>>
>>
>> >javap -private Foo$Bar1$
>>
>> public final class Foo$Bar1$ extends java.lang.Object implements
>> scala.ScalaObject{
>> public Foo$Bar1$(Foo);
>> public void bar();
>> }
>>
>> Ken
>>

[Naftoli Gugenheim]

An object gets its own type. It can be useful when fields need to know their name...