Re: semantics of multithreading?

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail
From	usenet@mkarcher.dialup.fu-berlin.de (Michael Karcher)
Newsgroups	comp.std.c++
Subject	Re: semantics of multithreading?
Date	Tue, 18 Jun 2013 11:36:47 -0700 (PDT)
Organization	Freie Universitaet Berlin
Lines	33
Sender	std-cpp-request@vandevoorde.com
Approved	stephen.clamage@oracle.com
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>
NNTP-Posting-Host	1xVqKfip0ZR/pjzetbvUYqb8xwvs7r2FClxN6BFmR3A=
X-Trace	news.albasani.net 8nr7czcwdr0Z0u/e3R3RZfxZJGt1ZijsLAHi/sMvVahyLhbiV84ErHgOp/05fkQt30lCD5p+2oz8qGRlAanmjg==
X-Complaints-To	abuse@albasani.net
NNTP-Posting-Date	Tue, 18 Jun 2013 18:36:50 +0000 (UTC)
X-Mailer	Perl5 Mail::Internet v2.05
X-Submission-Address	std-cpp-submit@vandevoorde.com
Cancel-Lock	sha1:um9a7mRLTBdLn6Lm5oHwQn8SAUM=
X-Original-Date	17 Jun 2013 20:51:15 GMT
Xref	csiph.com comp.std.c++:643

Show key headers only | View raw

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

Thread

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