Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26452

Re: java.util.concurrent.atomic

Show all headers | View raw

On 29.10.13 21.35, Andreas Leitgeb wrote:
> Kevin McMurtrie<mcmurtrie@pixelmemory.us>  wrote:
>> Why use code that can never block? [...]
>
> That would be fine, if the code really didn't block, but if it
> ends up doing the "do { ... } while (...)" idiom, then it really
> IS blocking, just in a bad way.

As long as your algorithm ensures forward progress, the number of loops 
should be finite. But in theory it might end up O(n^2) with n the number 
of parallel jobs (the first job terminates after first loop, the second 
job after two loops and so on). In practice optimistic locking performs 
significantly better most of the time. Typically the probability of 
taking more turns until success decreases exponentially.

The idea behind the scenes is that doing a handshake for synchronization 
is more expensive than doing the work twice. In fact we are close to the 
limits given by Einsteins theory of relativity. Correlated events in 
space-time must reachable by the speed of light. In a 1 GHz clock cycle 
(nothing special nowadays) you can synchronize over a distance of about 
10 cm. Larger distances take longer. This is sufficient for multi-core, 
critical for multi-chip servers and impossible for network clusters.

> What would be usecases of non-blocking synchronisation that don't
> end up polling until success?

Intrinsically atomic operations do not require CAS loops. E.g. atomic 
increments/decrements for reference counting perform O(1).

In other algorithms a CAS fail might end up in a way that another 
parallel thread does the job for my thread. In this case the number of 
instructions is still O(1).


Marcel

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

java.util.concurrent.atomic markspace <markspace@nospam.nospam> - 2013-10-26 17:25 -0700
  Re: java.util.concurrent.atomic Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-10-26 19:56 -0700
    Re: java.util.concurrent.atomic Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-29 20:35 +0000
      Re: java.util.concurrent.atomic Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-10-29 17:27 -0400
      Re: java.util.concurrent.atomic Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-10-29 22:36 +0100
      Re: java.util.concurrent.atomic Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-10-29 21:17 -0700
  Re: java.util.concurrent.atomic Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-10-27 10:09 +0100

csiph-web