lazy vals in objects received in actor

[Tim Pigden]

Hi

I have an immutable object inherited from non-akka code with a number of lazy vals declared within in - which cause some modest amount of processing. They are not sufficiently time-consuming to warrant a separate actor/thread to calculate them but I'd rather not have to change them to defs - the client code elsewhere assumes that they'll only be calculated once - or vals, since the results may never be used.

Lazy val has always seemed to me like a good idea for this sort of thing. But what are the implications if used in an object within Akka. I don't care about wasted time in the extremely unlikely event that 2 actors inspect the lazy val at the "same" time and both cause a calculation. But is the assignment of a real value to the lazy val thread-safe? 

Tim

[bryan hunt]

"But is the assignment of a real value to the lazy val thread-safe?"

Not to be pedantic, but I would re-phrase that sentence as, "the evaluation of a lazy val to a real value".

I would have also thought that it might be evaluated twice.

However examining the bytecode indicated otherwise.

Using the Intellij ASM Bytecode outline plugin (kudos to it's creator), I decompiled the following object:

  object Lazy {
    import scala.util.Random
    val bar = "hello " + Random.nextLong() + " world "
  }


The code where the field is accessed decompiles to this:

// access flags 0x1
  public bar()Ljava/lang/String;
    ALOAD 0
    GETFIELD Lazy$.bitmap$0 : Z
    IFEQ L0
    ALOAD 0
    GETFIELD Lazy$.bar : Ljava/lang/String;
    GOTO L1
   L0
   FRAME SAME
    ALOAD 0
    INVOKESPECIAL Lazy$.bar$lzycompute ()Ljava/lang/String;

OK, so no synchronization there. It just checks if it's null, then calls lzycompute if necessary.

But, looking at the lzycompute implementation...

 private bar$lzycompute()Ljava/lang/String;
    TRYCATCHBLOCK L0 L1 L2 null
    ALOAD 0
    DUP
    ASTORE 1
    MONITORENTER
   L0
    ALOAD 0
    GETFIELD Lazy$.bitmap$0 : Z
    IFNE L3
    ALOAD 0
    NEW scala/collection/mutable/StringBuilder
    DUP
    INVOKESPECIAL scala/collection/mutable/StringBuilder.<init> ()V
    LDC "hello "
    INVOKEVIRTUAL scala/collection/mutable/StringBuilder.append (Ljava/lang/Object;)Lscala/collection/mutable/StringBuilder;
 
We see that the string concatenation operations are run inside a synchronised try/catch block.

So at least in this case, evaluation of the expression is thread safe, but it may be evaluated multiple times.

Hope this helps,

Bryan

[Tim Pigden]

Excellent. Many thanks

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/MOk7oMWg5yg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England 
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.