Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #26450
| From | Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: java.util.concurrent.atomic |
| Date | 2013-10-29 20:35 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <slrnl70709.mol.avl@gamma.logic.tuwien.ac.at> (permalink) |
| References | <l4hmhq$282$1@dont-email.me> <mcmurtrie-6228FA.19564926102013@c-61-68-245-199.per.connect.net.au> |
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.
What would be usecases of non-blocking synchronisation that don't
end up polling until success?
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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