"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
On Tuesday, March 4, 2014 9:20:42 AM UTC, Tim Pigden wrote:
>
> 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
>
--
>>>>>>>>>> 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 the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.
