Excellent. Many thanks

On 5 March 2014 13:03, bryan hunt <[email protected]> wrote:

>
> "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 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
> [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.
>



-- 
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.

-- 
>>>>>>>>>>      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.

Reply via email to