Re: Thread safety and atomic assignment (again)

On Apr 30, 2:38 pm, Philipp <sicsic...@xxxxxxxxxxx> wrote:

...
The question: Are the following code snippets thread safe and why? (my
opinion is on top, please correct if wrong):

What is your definition of thread safeness in the case of your
examples?

// Not thread safe. "value" needs to be volatile, else another thread
// might see a stale value
public final class Test1 {
     private int value = 0;

     public int getValue() {
         return value;
     }
     public void setValue(int value) {
         this.value = value;
     }
}

This construction is regarded not to be thread safe. However, with
volatile int, you only solve the so-called visibility problem but I
would not regard the whole class thread safe even with the volatile
int. Here the question again what do you regard to be a stale value.

// Not thread safe. Because assignment to long is not atomic (although
// volatile).
public final class Test2 {
     private volatile long value = 0;

     public long getValue() {
         return value;
     }
     public void setValue(long value) {
         this.value = value;
     }
}

Atomicity and volatileness are two different issues: "Locking can
guarantee both visibility and atomicity; volatile variables can only
guarantee visibility." (Java Concurrency in Practice, By Brian Goetz,
Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea)

As far as I know, however, single read or single write is atomic in
case of volatile long, so it should be thread safe in your
interpretation of thread safeness.

I think the rest of the examples, Test3-5 are all unsafe because of
the same reason: Atomicity and volatileness are two different issues.
In those cases you require atomicity to make it thread safe.

Best Regards,
Szabolcs
.

Relevant Pages

  • Re: Thread safety and atomic assignment (again)
    ... By making the internal field volatile, you have made your class data- ... Are the following code snippets thread safe and why? ... Atomicity and volatileness are two different issues: ... guarantee both visibility and atomicity; ...
    (comp.lang.java.programmer)
  • Re: Thread safety of collections
    ... > public static members are thread safe, ... > can a collection be accessed safely via multiple threads ... > calling non static methods if the collection is not ... make sure that there's a volatile write in whatever thread sets up the ...
    (microsoft.public.dotnet.framework)
  • Re: hashtable - thread safety clarification
    ... "Hashtable is thread safe for use by multiple reader threads and a single writing thread." ... if I am using a hashtable just like described above, multiple threads read from in but only one thread changes it, should I still be declaring it as 'volatile'? ... internal structure - it does not cover thread safety in general. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Interlocked.Increment ?
    ... My understanding is that volatile word needs to be specified so compiler ... > InterLocked .Increment is not targeted to be used with volatile modifier. ... >> Interlocked.Increment increments the variable in thread safe manner. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x
    ... They may mean that writes get "as much atomicity" between threads as ... libraries that did "magic things" with select loops etc for IO using ... That would explain the POSIX wording - that they are supposed to be "as ... thread safe" as a native write, even when they are wrapped inside a magic ...
    (Linux-Kernel)