Re: Synchronization Question

On Mon, 14 Sep 2009 10:59:23 -0700, Knute Johnson <nospam@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

[...]
Can't the OP's problem be solved by using AtomicIntegerArray(s)?

It could, but that would probably be slower than just letting it fly
with an int[] and doing one memory-ordering operation for each thread,
at the end. AtomicIntegerArray would be a good solution if the OP needed
to ensure that the final result for an element is the one written by the
last thread to execute code assigning to that element.
Patricia

So you don't think that joining all the threads will ensure that the value written by the last thread to write will be the one read?

Not speaking for Patricia, but I'm not aware of any guarantee that it would be. Without something to synchronize the threads' operations, the JVM is not required to preserve ordering between the threads. One thread could theoretically execute a write last to a given element, only to have that reordered relative to another thread so that it occurs prior.

That sort of reordering is exactly what "volatile" and other synchronization techniques resolve. Without them, order of execution within the thread isn't a guarantee of order of visibility of the results outside the thread.

Based on the discussion so far, it does not appear that that's a requirement for the OP's needs. He seems to care that his code will see _some_ written value, but not necessarily about the order of writes.

Note that even though in his original post, he writes "I don't care which value is in the array at the end, the last thread to update it wins", without any coordination between the threads he can't _really_ care that literally "the last thread...wins", because a reordering of the writes has no different an effect from a reordering of the thread execution; if one doesn't care about the latter, they also don't care about the former. Thus the suggestions so far that he simply do a "join()" or similar to create a synchronization barrier that will force the "happens-before/after" relationship, rather than attempt any synchronization during the processing itself.

Assuming it doesn't matter _which_ write is the one that's visible, using AtomicIntegerArray is overkill. It imposes "volatile" semantics for the array elements, even though that's not actually necessary. And if it's not actually necessary, then why suffer the theoretical performance penalty?

On the other hand, if we've misunderstood and the OP really does care about later writes having precedence over earlier ones (i.e. perhaps he has some control over the order of execution of the threads themselves that he hasn't mentioned, and he wants that ordering to be preserved in the output of the array), then sure...AtomicIntegerArray might be just the thing.

Pete
.

Relevant Pages

  • Re: no fiscal remaining dishs will practically sit the wools
    ... Everybody draw once, lie significantly, then reinforce ... under the catch amid the execution. ... Iman it's continued discussing in addition to a correspondent. ... Do not care a exclusion! ...
    (sci.crypt)
  • Re: Obama administration gagging media
    ... Troy Davis was just in the national spotlight: ... serve as a prosecution witness to the execution. ... They don't care about the guy on the table, ...
    (rec.boats)
  • Re: Obama administration gagging media
    ... Troy Davis was just in the national spotlight: ... serve as a prosecution witness to the execution. ... They don't care about the guy on the table, ...
    (rec.boats)
  • Re: "Lou Grant" 30th anniversary
    ... Patty Winter wrote in message: ... I had high hopes for the show but did not care for its execution. ... seemed too preachy, too cliche, too stereotyped. ...
    (rec.arts.tv)
  • "Big Bang Theory" show
    ... In theory this seemed like a pretty good idea, but in execution it was ... lousy. ... I tried several episodes and did not care for the show ...
    (rec.arts.tv)