Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | usenet@mkarcher.dialup.fu-berlin.de (Michael Karcher) |
|---|---|
| Newsgroups | comp.std.c++ |
| Subject | Re: semantics of multithreading? |
| Date | 2013-06-18 11:36 -0700 |
| Organization | Freie Universitaet Berlin |
| Message-ID | <b29b63FoklqU1@mid.uni-berlin.de> (permalink) |
| References | <b5950868-7d0a-4485-8c1e-166e74843669@googlegroups.com> <0deed2c4-9e51-406b-b608-68c4915dde3d@googlegroups.com> <80e6c857-659f-4b79-87a4-67419d665eed@googlegroups.com> <0385d20b-a476-4b85-bfa7-de533543a076@googlegroups.com> |
Jason McKesson <jmckesson@googlemail.com> wrote: > > I would argue that the above program can terminate -- it is not > > livelocked. > You can argue whatever you like; the standard doesn't agree. > > The standard is very clear on this; you may not *assume* that a thread > will ever execute past a certain point unless you use an explicit > ordering primitive like a thread ::join or a mutex. While you are most likely right that the standard makes no guarantee on this, it still discourages implementations that do not let the example program terminate. See N3337 1.10, clause 2: "Implementations should ensure that all unblocked threads eventually make progress". As in the example program, neither thread is blocked, the store in thread 2 should eventually be reached. It goes on to explain that for example thread priorities in the execution environment might make guarantees implossible. The example program does not contain a data race according to 1.10, clause 21, as all accesses are atomic, so this clause does not invoke undefined behaviour. Furthermore, also clause 24 is not violated, as the first thread in the example does perform atomic operations in its loop. Regards, Michael Karcher -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar
semantics of multithreading? siegebell@googlemail.com - 2013-06-10 12:23 -0700
Re: semantics of multithreading? Jason McKesson <jmckesson@googlemail.com> - 2013-06-11 12:19 -0700
Re: semantics of multithreading? Martin Bonner <martinfrompi@yahoo.co.uk> - 2013-06-13 08:42 -0700
Re: semantics of multithreading? siegebell@googlemail.com - 2013-06-15 08:42 -0600
Re: semantics of multithreading? Jason McKesson <jmckesson@googlemail.com> - 2013-06-16 19:58 -0600
Re: semantics of multithreading? usenet@mkarcher.dialup.fu-berlin.de (Michael Karcher) - 2013-06-18 11:36 -0700
Re: semantics of multithreading? siegebell@googlemail.com - 2013-06-23 19:19 -0600
Re: semantics of multithreading? siegebell@googlemail.com - 2013-06-23 19:18 -0600
csiph-web