Re: visibility on array elements

neuneudr@xxxxxxxx wrote:
Hi,

imagine that for whatever reason I decide *not* to use an
AtomicLongArray and go with a long[] (the reason is
actually that I want to understand what's going on).

public static final long[] ref = new long[42];

Do the following guarantee the correct visibility
when accessing the elements of the array :

From one thread :

synchronized (ref) {
ref[0] = 3;
}

and from another thread, later :

synchronized (ref) {
long val = ref[0]; // Am I guaranteed to get back '3'
here ?
}

Yes, you'll get 3L (assuming nothing else has disturbed
ref[0] in the meantime).

Basically my question is : seen that array elements cannot
be declared volatile *and* that I want to use arrays, how
should I proceed if I want thread-safe behavior when
modifying/reading my array ?

You can synchronize all accesses on the array itself, as
above, in which case no accesses will overlap and modifications
made by any thread will be visible to all others. Note that
this may create more contention than if you could somehow
synchronize on the individual elements, because it prohibits
simultaneous access to ref[0] and ref[1].

Using synchronized access (or volatile) does not in and of
itself guarantee "thread-safe behavior." A classic example is

Vector<String> v = new Vector<String>();
...
if (! v.isEmpty()) {
String s = v.remove(0);
...

This fragment is not thread-safe, even though the individual
..isEmpty() and .remove() methods are synchronized and hence
thread-safe insofar as their own operations are concerned.

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: How do I use the Java API in a Thread-Safe Manner?
    ... it's not necessary to synchronize the `new' operator. ... > You probably need to synchronize access to `sbStr', ... declared as a local variable (which would make it it thread-safe, ... since that means every other piece of Java code ...
    (comp.lang.java.programmer)
  • Re: How do I use the Java API in a Thread-Safe Manner?
    ... assume that the API is *not* thread-safe unless it states that it is (such ... If the API is ... method, call it UnsafeAPI() that is not thread-safe, therefore ... ... stated above when you said "There's no effective way to synchronize access ...
    (comp.lang.java.programmer)
  • Re: Should we always call EndInvoke()?
    ... safe static .Net members. ... programmer  has to make sure that all the different thread-safe ... classes are automatically thread-safe with respect to each other, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Question about synchronization with vectors
    ... > I have read how to synchronize using the sychronize keyword around the ... > thread-safe. ... Alex Kizub. ...
    (comp.lang.java.programmer)
  • Re: PTHREAD_MUTEX_INITIALIZER
    ... so it must be thread-safe. ... reason internal to the implementation, so you need to check the return ... pthread_mutex_lock fails. ... Guess what many 'abort' implementations ...
    (comp.programming.threads)