Scala thread-safety question

"object" initialization is thread safe. "mutable.List" is not thread
safe and needs to be synchronized.

On Mon, Jun 7, 2010 at 9:27 PM, Ravi Mendis wrote:
> Is the following val Class.students thread-safe? Or does modification to it need to be synchronised somehow like in Java?
>
> object Class {
>        val students = new mutable.List()
> }
>

object Class {
lazy val students = new mutable.List()
}

On 06/07/2010 07:12 PM, Lex wrote:
> "object" initialization is thread safe. "mutable.List" is not thread
> safe and needs to be synchronized.
>
> On Mon, Jun 7, 2010 at 9:27 PM, Ravi Mendis wrote:
>> Is the following val Class.students thread-safe? Or does modification to it need to be synchronised somehow like in Java?
>>
>> object Class {
>> val students = new mutable.List()
>> }
>>
>

Can someone please explain how setting the immutable list as "lazy" will make adding to or removing objects from the list thread-safe? Thx.

On 08/06/2010, at 12:15 PM, richard emberson wrote:

> object Class {
> lazy val students = new mutable.List()
> }
>
> On 06/07/2010 07:12 PM, Lex wrote:
>> "object" initialization is thread safe. "mutable.List" is not thread
>> safe and needs to be synchronized.
>>
>> On Mon, Jun 7, 2010 at 9:27 PM, Ravi Mendis wrote:
>>> Is the following val Class.students thread-safe? Or does modification to it need to be synchronised somehow like in Java?
>>>
>>> object Class {
>>> val students = new mutable.List()
>>> }
>>>
>>
>

Firstly, I assume when you say "immutable", I think you mean
"mutable": an immutable list by definition is always thread-safe.

Secondly, no, setting a mutable list as lazy will not make it thread-safe.

Ishaaq

On 8 June 2010 16:18, Ravi Mendis wrote:
> Can someone please explain how setting the immutable list as "lazy" will make adding to or removing objects from the list thread-safe? Thx.
>
> On 08/06/2010, at 12:15 PM, richard emberson wrote:
>
>> object Class {
>> lazy val students = new mutable.List()
>> }
>>
>> On 06/07/2010 07:12 PM, Lex wrote:
>>> "object" initialization is thread safe. "mutable.List" is not thread
>>> safe and needs to be synchronized.
>>>
>>> On Mon, Jun 7, 2010 at 9:27 PM, Ravi Mendis  wrote:
>>>> Is the following val Class.students thread-safe? Or does modification to it need to be synchronised somehow like in Java?
>>>>
>>>> object Class {
>>>>      val students = new mutable.List()
>>>> }
>>>>
>>>
>>
>> --
>> Quis custodiet ipsos custodes
>
>

Yes - i mean mutable. Soz.

Perhaps i'm still thinking Java? Maybe the Scala way is:

object Class {
var students = new List() // immutable
}

So will the setting of Class.students now be thread-safe?

On 08/06/2010, at 4:28 PM, Ishaaq Chandy wrote:

> Firstly, I assume when you say "immutable", I think you mean
> "mutable": an immutable list by definition is always thread-safe.
>
> Secondly, no, setting a mutable list as lazy will not make it thread-safe.
>
> Ishaaq
>
> On 8 June 2010 16:18, Ravi Mendis wrote:
>> Can someone please explain how setting the immutable list as "lazy" will make adding to or removing objects from the list thread-safe? Thx.
>>
>> On 08/06/2010, at 12:15 PM, richard emberson wrote:
>>
>>> object Class {
>>> lazy val students = new mutable.List()
>>> }
>>>
>>> On 06/07/2010 07:12 PM, Lex wrote:
>>>> "object" initialization is thread safe. "mutable.List" is not thread
>>>> safe and needs to be synchronized.
>>>>
>>>> On Mon, Jun 7, 2010 at 9:27 PM, Ravi Mendis wrote:
>>>>> Is the following val Class.students thread-safe? Or does modification to it need to be synchronised somehow like in Java?
>>>>>
>>>>> object Class {
>>>>> val students = new mutable.List()
>>>>> }
>>>>>
>>>>
>>>
>>> --
>>> Quis custodiet ipsos custodes
>>
>>

On Tue, Jun 08, 2010 at 04:28:14PM +1000, Ishaaq Chandy wrote:
> Firstly, I assume when you say "immutable", I think you mean
> "mutable": an immutable list by definition is always thread-safe.

Boy, that'd be nice. By definition! Sadly an immutable structure is
threadsafe "by definition" the same way I am the coolest guy in the room
"by definition". It might be true sometimes or even most of the time,
but it doesn't have that definitive definition aspect. One example:

https://lampsvn.epfl.ch/trac/scala/ticket/1610
"immutable HashMap fails in highly concurrent updates"

Maybe you are using some extremely restricted definition of an immutable
list, but any definition for which threadsafety comes by definition is
not likely to model the real world.

> Secondly, no, setting a mutable list as lazy will not make it thread-safe.

That much is true.

On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
> object Class {
> var students = new List() // immutable
> }
>
> So will the setting of Class.students now be thread-safe?

Are you using "thread-safe" with some meaning in mind? Are you asking if
reference assignment is atomic? It is.

I mean if in one thread we do:

Class.students = myListOfStudents // assume this exists

Then this won't cause a deadlock if some other thread accesses Class.students concurrently...

On 08/06/2010, at 5:07 PM, Paul Phillips wrote:
> On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
>> object Class {
>> var students = new List() // immutable
>> }
>>
>> So will the setting of Class.students now be thread-safe?
>
> Are you using "thread-safe" with some meaning in mind? Are you asking if
> reference assignment is atomic? It is.

:) As I hit "send" on that post I cringed as I realised what I had
implied by saying "by definition".

I guess what I meant was, immutability should imply thread-safety,
and, if it does not do so, then that is a bug.

Ishaaq

On 8 June 2010 17:07, Paul Phillips wrote:
> On Tue, Jun 08, 2010 at 04:28:14PM +1000, Ishaaq Chandy wrote:
>> Firstly, I assume when you say "immutable", I think you mean
>> "mutable": an immutable list by definition is always thread-safe.
>
> Boy, that'd be nice.  By definition! Sadly an immutable structure is
> threadsafe "by definition" the same way I am the coolest guy in the room
> "by definition".  It might be true sometimes or even most of the time,
> but it doesn't have that definitive definition aspect.  One example:
>
>  https://lampsvn.epfl.ch/trac/scala/ticket/1610
>  "immutable HashMap fails in highly concurrent updates"
>
> Maybe you are using some extremely restricted definition of an immutable
> list, but any definition for which threadsafety comes by definition is
> not likely to model the real world.
>
>> Secondly, no, setting a mutable list as lazy will not make it thread-safe.
>
> That much is true.
>
> On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
>> object Class {
>>       var students = new List()   // immutable
>> }
>>
>> So will the setting of Class.students now be thread-safe?
>
> Are you using "thread-safe" with some meaning in mind? Are you asking if
> reference assignment is atomic? It is.
>
> --
> Paul Phillips      | All men are frauds.  The only difference between
> Everyman           | them is that some admit it.  I myself deny it.
> Empiricist         |     -- H. L. Mencken
> i pull his palp!   |----------* http://www.improving.org/paulp/ *----------
>

On Tue, Jun 8, 2010 at 8:07 AM, Paul Phillips wrote:
> Are you using "thread-safe" with some meaning in mind? Are you asking if
> reference assignment is atomic? It is.

It's worth mentioning that visibility is not guaranteed unless the
field is volatile.

Best,
Ismael

Ravi,
I don't think you've really answered Paul's question.

Expanding on what Paul was implying: "thread-safety" is an ambiguous
requirement. It can imply a number of things. What you implement
depends on a number of questions you need to first answer about your
requirements:

1. Do you care if a particular thread gets stale data as long as it is
consistent within a block of code?
2. Do you care if readers may get stale but consistent data as in
point 1 above, as long as writers get synchronised data?
3. Do you want a completely synchronised view of the data - i.e. all
threads consistently see the most up-to-date data all the time
(difficult to achieve without slow-downs/deadlocks)

Those were just off the top of my head, there may be other things to consider.

If you absolutely must use concurrently mutable data structures, then,
unless you understand Java threading really well, you're probably
safest to consider using third-party concurrency APIs like Actors, STM
or Java's own native concurrency api.

Ishaaq

On 8 June 2010 17:14, Ravi Mendis wrote:
> I mean if in one thread we do:
>
> Class.students = myListOfStudents  // assume this exists
>
> Then this won't cause a deadlock if some other thread accesses Class.students concurrently...
>
> On 08/06/2010, at 5:07 PM, Paul Phillips wrote:
>> On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
>>> object Class {
>>>      var students = new List()   // immutable
>>> }
>>>
>>> So will the setting of Class.students now be thread-safe?
>>
>> Are you using "thread-safe" with some meaning in mind? Are you asking if
>> reference assignment is atomic? It is.
>
>

On Tue, Jun 8, 2010 at 9:38 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, Jun 8, 2010 at 8:07 AM, Paul Phillips <paulp@improving.org> wrote:
> Are you using "thread-safe" with some meaning in mind? Are you asking if
> reference assignment is atomic? It is.

It's worth mentioning that visibility is not guaranteed unless the
field is volatile.

if the field is not captured by closures... brrr...
 

Best,
Ismael

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

On 08/06/2010, at 5:49 PM, Ishaaq Chandy wrote:
> I don't think you've really answered Paul's question...

Well i think Paul answered my question...

>> On 08/06/2010, at 5:07 PM, Paul Phillips wrote:
>>> Are you asking if reference assignment is atomic? It is.

Basically, yes.

> On 8 June 2010 17:14, Ravi Mendis wrote:
>> I mean if in one thread we do:
>>
>> Class.students = myListOfStudents // assume this exists
>>
>> Then this won't cause a deadlock if some other thread accesses Class.students concurrently...

Atomic => No deadlock here

>>> On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
>>>> object Class {
>>>> var students = new List() // immutable
>>>> }

Just to elaborate a bit more. The atomicity of assignments for
references is dictated by the VM memory model, Scala has nothing to do
with it. So the question that remains does this also hold true on .NET
runtime of scala?

And what about Long and Double are these atomic when used or does this
depend on what the scala compiler does with them?

-Stefan

2010/6/9 Ravi Mendis :
>
> On 08/06/2010, at 5:49 PM, Ishaaq Chandy wrote:
>> I don't think you've really answered Paul's question...
>
> Well i think Paul answered my question...
>
>>> On 08/06/2010, at 5:07 PM, Paul Phillips wrote:
>>>> Are you asking if reference assignment is atomic? It is.
>
> Basically, yes.
>
>> On 8 June 2010 17:14, Ravi Mendis wrote:
>>> I mean if in one thread we do:
>>>
>>> Class.students = myListOfStudents  // assume this exists
>>>
>>> Then this won't cause a deadlock if some other thread accesses Class.students concurrently...
>
> Atomic => No deadlock here
>
>>>> On Tue, Jun 08, 2010 at 04:56:01PM +1000, Ravi Mendis wrote:
>>>>> object Class {
>>>>>      var students = new List()   // immutable
>>>>> }
>
>