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

Groups > comp.std.c++ > #640

Re: semantics of multithreading?

Show all headers | View raw

On Monday, June 10, 2013 8:23:21 PM UTC+1, sieg...@googlemail.com wrote:
> Consider a program that forks two threads, each of which atomically
> sets the value of the same variable to different values, and then
> joins the threads and prints the value of the variable. Depending
> on the outcome of the thread interleaving, a different value may
> be printed.
Yes.

[snip sample code]
>
>
> Does the C++11 standard explicitly state whether the compiler is
> required to preserve all thread interleavings that may result in
> different outputs? Or can it be treated as "unspecified behavior",
> allowing the compiler to choose fewer interleavings?

I don't understand what you mean by that, but I am fairly sure the
compiler is allowed to optimize to:

int main()
{
   cout << "2";
   return 0;
}

in other words, it can assume that one thread will always run after
after the other, and optimize on that basis.

> I am suspicious of the latter case because it could allow the
> compiler to introduce a deadlock or livelock in some programs.

I don't see how.  The compiler can optimize in a way that eliminates
certain possible orderings, but if there is a deadlock in the ordering
it chooses then that can happen anyway.

> Also, I associate "unspecified behavior" with choices that the compiler
> may make, but if the choice has an stateful effect, then the program is
> undefined.
I don't understand that.  If you write

   a = f(1) + g(2);

then it is unspecified if f or g is called first (but one of them will be).
You can write code which produces output that depends on that (write output
in both functions), but the behaviour is perfectly well defined (just the
order is unspecified).

> If choosing a particular thread interleaving does not result
> in a different output (or "observable behavior"), may the
> compiler do so? Does the standard allow new threads to be
> introduced, e.g. to automatically parallelize a program?


If you can't tell the difference, then the as-if rule says "yes".


-- 
[ 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