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

Groups > comp.unix.programmer > #673 > unrolled thread

threads, signals, and atomicity of basic types

Back to article view | Back to comp.unix.programmer

Contents

  threads, signals, and atomicity of basic types Urs Thuermann <urs@isnogud.escape.de> - 2011-05-31 21:07 +0200
    Re: threads, signals, and atomicity of basic types Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-31 22:44 +0200
      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-01 11:58 +0100
        Re: threads, signals, and atomicity of basic types Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-06-01 14:15 +0200
          Re: threads, signals, and atomicity of basic types Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-06-02 13:49 +0200
            Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 13:40 +0100
    Re: threads, signals, and atomicity of basic types Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-31 22:50 +0100
    Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-31 21:32 -0400
      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-01 12:35 +0100
        Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-01 23:01 -0400
          Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 11:22 +0100
            Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-02 07:52 -0400
              Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 13:38 +0100
                Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-02 21:27 -0400
    Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-01 12:55 -0700
      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-01 22:54 +0100
        Re: threads, signals, and atomicity of basic types Alex Fraser <me@privacy.net> - 2011-06-02 21:00 +0100
          Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-04 21:53 -0700
            Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-05 16:39 +0100
              Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-06 18:48 -0700
                Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-07 06:50 +0100
                  Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-07 06:04 -0700
                    Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-07 22:48 +0100
                      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-07 23:18 +0100
                        Re: threads, signals, and atomicity of basic types gordonb.lhpq6@burditt.org (Gordon Burditt) - 2011-06-07 18:28 -0500
                          Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-08 11:09 +0100
                            Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-08 14:32 -0700
                            Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-09 18:10 -0700
                              Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-10 15:26 +0100
                                Re: threads, signals, and atomicity of basic types James Waldby <not@valid.invalid> - 2011-06-10 16:49 +0000
                                  Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-10 19:07 +0100
                                  Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-10 13:13 -0700
                Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-07 12:55 +0100
                  Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-07 06:02 -0700
                    Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-07 16:05 +0100
                      Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-07 13:37 -0700
                        Re: threads, signals, and atomicity of basic types scott@slp53.sl.home (Scott Lurndal) - 2011-06-14 21:43 +0000
                          Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-15 03:07 +0100
                            Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-15 10:22 +0100
                              Re: threads, signals, and atomicity of basic types Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-06-15 09:40 +0000
                                Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-15 13:20 +0100
                                  Re: threads, signals, and atomicity of basic types Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-06-15 13:19 +0000
                                  Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-15 17:41 +0100
                                  Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-15 20:20 -0700
                              Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-15 17:31 +0100
                                Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-15 18:31 +0100
                                  Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-15 13:32 -0700
                                  Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-15 22:19 +0100
                                  Re: threads, signals, and atomicity of basic types Nobody <nobody@nowhere.com> - 2011-06-16 05:02 +0100
                          Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-14 23:23 -0700
                        Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-15 10:12 +0100
                          Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-15 02:53 -0700
                      Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-08 10:19 -0700
                        Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-10 16:50 +0100
                          Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-15 20:24 -0700
                            Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-16 22:11 +0100
                              Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-17 04:43 -0700
                                Re: threads, signals, and atomicity of basic types Michael Press <rubrum@pacbell.net> - 2011-06-19 01:43 -0700
                                  Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-19 13:35 +0100
                                    Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-19 17:06 -0700
                                      Re: threads, signals, and atomicity of basic types scott@slp53.sl.home (Scott Lurndal) - 2011-06-20 16:22 +0000
                                        Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-20 19:16 +0100
                                          Re: threads, signals, and atomicity of basic types scott@slp53.sl.home (Scott Lurndal) - 2011-06-21 17:30 +0000
                                            Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-21 13:02 -0700
                                        Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-20 14:32 -0700
                                          Re: threads, signals, and atomicity of basic types scott@slp53.sl.home (Scott Lurndal) - 2011-06-21 17:05 +0000
                                  Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-19 17:01 -0700
                                    Re: threads, signals, and atomicity of basic types Michael Press <rubrum@pacbell.net> - 2011-06-22 01:55 -0700
                                      Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-22 03:36 -0700
        Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-02 21:53 -0700
        Re: threads, signals, and atomicity of basic types David Schwartz <davids@webmaster.com> - 2011-06-03 04:24 -0700
        Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-03 07:52 -0400
    Re: threads, signals, and atomicity of basic types "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-06-02 00:23 +0200
      Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 20:11 -0700
        Re: threads, signals, and atomicity of basic types "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-06-02 22:54 +0200
          Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 14:03 -0700
            Re: threads, signals, and atomicity of basic types "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-06-03 02:49 +0200
              Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 17:54 -0700
                Re: threads, signals, and atomicity of basic types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-02 21:36 -0400
                  Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-03 16:25 +0100
              Re: threads, signals, and atomicity of basic types "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-06-03 03:12 +0200
    Re: threads, signals, and atomicity of basic types "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-06-02 00:45 +0200
      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 11:26 +0100
        Re: threads, signals, and atomicity of basic types Alex Fraser <me@privacy.net> - 2011-06-02 21:05 +0100
    Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 20:21 -0700
      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 11:31 +0100
        Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 09:12 -0700
          Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-02 17:54 +0100
            Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 14:00 -0700
              Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-03 15:19 +0100
                Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-03 15:50 -0700
                  Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-05 16:46 +0100
                    Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-05 15:28 -0700
                      Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-06 13:35 +0100
                        Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 09:19 -0700
                        Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 09:26 -0700
                        Re: threads, signals, and atomicity of basic types Ian Collins <ian-news@hotmail.com> - 2011-06-07 09:43 +1200
                          Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-07 13:29 +0100
                            Re: threads, signals, and atomicity of basic types Ian Collins <ian-news@hotmail.com> - 2011-06-08 09:04 +1200
                              Re: threads, signals, and atomicity of basic types Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-08 12:34 +0100
                                Re: threads, signals, and atomicity of basic types Ian Collins <ian-news@hotmail.com> - 2011-06-09 07:37 +1200
                        Re: threads, signals, and atomicity of basic types Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-07 14:55 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#722

(Sorry for the self-followup.)

On Fri, 3 Jun 2011, Ersek, Laszlo wrote:

> When in state (a), an async SIGCONT will be made pending for the process 
> (if the process was also stopped, it will continue running, but the 
> signal will only become pending).

I forgot:

naturally, while being in the same "instance" of state (a) (ie. not 
"crossing" the pselect() call), the process can be stopped and continued 
many times. Adjacent SIGCONTs coalesce into a single pending SIGCONT 
(should no SIGSTOP intervene), and a SIGSTOP will discard any pending 
SIGCONT.

lacos

[toc] | [prev] | [next] | [standalone]

#686

On Tue, 31 May 2011, Urs Thuermann wrote:

> volatile

Can't resist posting this again:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html

lacos

[toc] | [prev] | [next] | [standalone]

#701

"Ersek, Laszlo" <lacos@caesar.elte.hu> writes:
> On Tue, 31 May 2011, Urs Thuermann wrote:
>> volatile
>
> Can't resist posting this again:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html

A programming manual for some piece of hardware where read accesses to
objects residing at certain memory locations actually produce side
effects could help all of these people a lot ...

[toc] | [prev] | [next] | [standalone]

#715

On 02/06/2011 11:26, Rainer Weikusat wrote:
> "Ersek, Laszlo"<lacos@caesar.elte.hu>  writes:
>> On Tue, 31 May 2011, Urs Thuermann wrote:
>>> volatile
>>
>> Can't resist posting this again:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html
>
> A programming manual for some piece of hardware where read accesses to
> objects residing at certain memory locations actually produce side
> effects could help all of these people a lot ...

There are surely many - probably the manual for pretty much any 
microcontroller with an integrated UART or similar. It wouldn't surprise 
me if memory-mapped hardware was the original rationale for volatile, as 
volatile's semantics are a perfect match (I guess this was your point).

Alex

[toc] | [prev] | [next] | [standalone]

#695

On May 31, 12:07 pm, Urs Thuermann <u...@isnogud.escape.de> wrote:
> Yet another question:  Do I need to use volatile to prevent compiler
> optimization even if I protect data with a pthread_mutex?

Optimizations are (almost) always under the "as if" rule. Your code
should be agnostic as to whether there are optimizations. You should
use the tools available, and their guarantees, to write your code.
Even asking that question indicates that you have a mistake somewhere
in your understanding. What you should be asking is "What tools do I
need to use to get the guarantees that my code will do what I want?".

If you're worried about inter-thread communication, volatile is
useless. Do not use it. The utility of volatile for portable inter-
thread communication is a urban legend which continues to be
perpetuated despite the community's best attempts to kill it. (It
doesn't help that up until like 7-8 years ago, community experts
thought that it worked. It does not.)

(I will note that this is all for portable code. If you're writing to
a particular implementation, and/or writing assembly, then the answers
are different.)

Volatile was introduced into C for 3 distinct reasons:
1- As a hook for MMIO.
2- To allow use of objects between setjump longjump nonsense.
3- To allow use of objects from a signal handler and normal path
code.

From my limited understanding, volatile is woefully insufficient for
MMIO on all relevant platforms. I don't want to even think about
setjump and longjump. As for signal handling, as you've noticed you
need more than just visibility guarantees, which is what volatile
gives you w.r.t. signal handlers, but you also need atomicity, which
volatile does not give you. That's where sig_atomic_t comes in. Even
then, AFAIK you're only guaranteed visibility when the signal handler
is executed by the same thread. This is also about where my knowledge
ends. I'm not familiar at all with signal handling.

Like, for example, is it a race condition and thus undefined behavior
if you read from a sig_atomic_t variable from one thread while another
thread is writing to it in a signal handler? What does POSIX say about
this, and what does C++0x say about this? I don't know offhand.

I'm largely echoing what has been beautifully described else-thread by
Laszlo Ersek.

[toc] | [prev] | [next] | [standalone]

#702

Joshua Maurice <joshuamaurice@gmail.com> writes:

[...]

> If you're worried about inter-thread communication, volatile is
> useless. Do not use it. The utility of volatile for portable inter-
> thread communication is a urban legend which continues to be
> perpetuated despite the community's best attempts to kill it.

And the general uselessness of volatile which is supposed to follow
from the original misunderstanding of its purpose is another urban
legend perpetuated by the same 'experts' who created the first one.

[...]

> From my limited understanding, volatile is woefully insufficient for
> MMIO on all relevant platforms.

It is the only way to inform a standards-compliant C compiler that
read accesses to some object produce side effects. Which they often do
for memory mapped device control operations, eg, reading an interrupt
register which resets itself upon read.

> I don't want to even think about setjump and longjump.

Then, you are unlikely to understand their uses, either.

[toc] | [prev] | [next] | [standalone]

#711

On Jun 2, 3:31 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
>
> > If you're worried about inter-thread communication, volatile is
> > useless. Do not use it. The utility of volatile for portable inter-
> > thread communication is a urban legend which continues to be
> > perpetuated despite the community's best attempts to kill it.
>
> And the general uselessness of volatile which is supposed to follow
> from the original misunderstanding of its purpose is another urban
> legend perpetuated by the same 'experts' who created the first one.

I have not claimed that volatile is useless. I have claimed that
volatile is useless for portable threading. Are you suggesting that as
a matter of facts volatile is portably useful for threading? This is
demonstrably incorrect. Are you just being contrarian for no
particular purpose, or do you mean to engage in a strawman?

http://en.wikipedia.org/wiki/Straw_man

> > From my limited understanding, volatile is woefully insufficient for
> > MMIO on all relevant platforms.
>
> It is the only way to inform a standards-compliant C compiler that
> read accesses to some object produce side effects. Which they often do
> for memory mapped device control operations, eg, reading an interrupt
> register which resets itself upon read.

As I said, it is my understanding that as a matter of fact, for most
desktops and servers, volatile plus knowledge of the memory addresses
is insufficient to do correct MMIO. You would need to use other
implementation specific hackery. Are you suggesting that this is
wrong? Are you suggesting that I was being overly narrow by
considering only desktops? Or are you just being contrarian and
engaging in strawman?

[toc] | [prev] | [next] | [standalone]

#712

Joshua Maurice <joshuamaurice@gmail.com> writes:
> On Jun 2, 3:31 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> Joshua Maurice <joshuamaur...@gmail.com> writes:
>>
>> > If you're worried about inter-thread communication, volatile is
>> > useless. Do not use it. The utility of volatile for portable inter-
>> > thread communication is a urban legend which continues to be
>> > perpetuated despite the community's best attempts to kill it.
>>
>> And the general uselessness of volatile which is supposed to follow
>> from the original misunderstanding of its purpose is another urban
>> legend perpetuated by the same 'experts' who created the first one.
>
> I have not claimed that volatile is useless. I have claimed that
> volatile is useless for portable threading. Are you suggesting that as
> a matter of facts volatile is portably useful for threading?

Trivially, since the meaning of volatile is completely orthogonal to
'threading', the answer is obviously: "Yes it is" and the question
similar to 'are you suggesting that function calls are useful for
portable threading?' and the general advice "Do not use it" is
nonsense. 

> This is demonstrably incorrect.

Something you (and/or , all kinds of other people) wrongly believed to
be the purpose of 'volatile' (I'm not even certain what this was
exactly supposed to be) is 'demonstrably' not its purpose. But this
doesn't mean that I share or ever shared this wrong belief.

For instance, assuming that a platform for single-word memory accesses
are atomic provided they are correctly aligned is being used and that
a compiler actually aligns them correctly (which, for all practical
purposes, means 'assuming that a computer and a C compiler are being
used') and the following code snippet 

	static int b;

        while (!b);
        printf("b is now %d\n", b);

was being executed by one thread of a multi-threaded program and some
other thread will eventually modify b, the declaration really ought to
be

	static volatile int b;

in order to inform the compiler that the code above is not
semantically equivalent to

             while (1);

because of 'something' (this is actually the 'volatile sig_atomic_t'
signal handler case in disguise).

[...]

>> > From my limited understanding, volatile is woefully insufficient for
>> > MMIO on all relevant platforms.
>>
>> It is the only way to inform a standards-compliant C compiler that
>> read accesses to some object produce side effects. Which they often do
>> for memory mapped device control operations, eg, reading an interrupt
>> register which resets itself upon read.
>
> As I said, it is my understanding that as a matter of fact, for most
> desktops and servers, volatile plus knowledge of the memory addresses
> is insufficient to do correct MMIO.

Yes. And on a similar note, the subtraction operator is insufficient
to write a desktop calculator program.

[toc] | [prev] | [next] | [standalone]

#717

On Jun 2, 9:54 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Something you (and/or , all kinds of other people) wrongly believed to
> be the purpose of 'volatile' (I'm not even certain what this was
> exactly supposed to be) is 'demonstrably' not its purpose. But this
> doesn't mean that I share or ever shared this wrong belief.

I never believed volatile was using for threading.

> For instance, assuming that a platform for single-word memory accesses
> are atomic provided they are correctly aligned is being used and that
> a compiler actually aligns them correctly (which, for all practical
> purposes, means 'assuming that a computer and a C compiler are being
> used') and the following code snippet
>
>         static int b;
>
>         while (!b);
>         printf("b is now %d\n", b);
>
> was being executed by one thread of a multi-threaded program and some
> other thread will eventually modify b, the declaration really ought to
> be
>
>         static volatile int b;
>
> in order to inform the compiler that the code above is not
> semantically equivalent to
>
>              while (1);
>
> because of 'something' (this is actually the 'volatile sig_atomic_t'
> signal handler case in disguise).

Yes, you should do that if you want to write a program with undefined
behavior. That program has a race condition under POSIX pthreads and
under C++0x, and according to either standard, a program with a race
condition has undefined behavior. Volatile does nothing to change
that.

If you want to write a non-portable program using likely undocumented
guarantees about its threading implementation, then sure, go for it.

[toc] | [prev] | [next] | [standalone]

#730

Joshua Maurice <joshuamaurice@gmail.com> writes:
> On Jun 2, 9:54 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

[...]

>> For instance, assuming that a platform for single-word memory accesses
>> are atomic provided they are correctly aligned is being used and that
>> a compiler actually aligns them correctly (which, for all practical
>> purposes, means 'assuming that a computer and a C compiler are being
>> used') and the following code snippet
>>
>>         static int b;
>>
>>         while (!b);
>>         printf("b is now %d\n", b);
>>
>> was being executed by one thread of a multi-threaded program and some
>> other thread will eventually modify b, the declaration really ought to
>> be
>>
>>         static volatile int b;
>>
>> in order to inform the compiler that the code above is not
>> semantically equivalent to
>>
>>              while (1);
>>
>> because of 'something' (this is actually the 'volatile sig_atomic_t'
>> signal handler case in disguise).
>
> Yes, you should do that if you want to write a program with undefined
> behavior.

For the situation I gave (which is virtually identical to 'the
situation'), this program will execute the while-loop until the change
to variable done by one thread (or 'the signal handler') is noticed by
the thread executing the loop. The behaviours isn't defined by any of
the possibly applicable standards because these are meant to be less
restrictive wrt platforms which can be used to implement
them. Especially, sig_atomic_t is a typedef name and this implies that
some native type which can safely be used in place of sig_atomic_t
must exist. Practically, this type will be 'int' because int is
supposed to be 'the most natural integer type for the architecture'
and correctly aligned single-world loads are atomic (actually, it
wouldn't even matter if they weren't atomic because the test is just
'is the value != 0').

> That program has a race condition under POSIX pthreads and
> under C++0x, and according to either standard, a program with a race
> condition has undefined behavior. Volatile does nothing to change
> that.

A 'race condition' is defined as 'code whose effects change, depending
on the order in which several threads do specific things, but without
any ordering explicitly imposed'. And there is no 'race condition' in
this example.

[toc] | [prev] | [next] | [standalone]

#734

On Jun 3, 7:19 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> > On Jun 2, 9:54 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> >> For instance, assuming that a platform for single-word memory accesses
> >> are atomic provided they are correctly aligned is being used and that
> >> a compiler actually aligns them correctly (which, for all practical
> >> purposes, means 'assuming that a computer and a C compiler are being
> >> used') and the following code snippet
>
> >>         static int b;
>
> >>         while (!b);
> >>         printf("b is now %d\n", b);
>
> >> was being executed by one thread of a multi-threaded program and some
> >> other thread will eventually modify b, the declaration really ought to
> >> be
>
> >>         static volatile int b;
>
> >> in order to inform the compiler that the code above is not
> >> semantically equivalent to
>
> >>              while (1);
>
> >> because of 'something' (this is actually the 'volatile sig_atomic_t'
> >> signal handler case in disguise).
>
> > Yes, you should do that if you want to write a program with undefined
> > behavior.
>
> For the situation I gave (which is virtually identical to 'the
> situation'), this program will execute the while-loop until the change
> to variable done by one thread (or 'the signal handler') is noticed by
> the thread executing the loop. The behaviours isn't defined by any of
> the possibly applicable standards because these are meant to be less
> restrictive wrt platforms which can be used to implement
> them. Especially, sig_atomic_t is a typedef name and this implies that
> some native type which can safely be used in place of sig_atomic_t
> must exist. Practically, this type will be 'int' because int is
> supposed to be 'the most natural integer type for the architecture'
> and correctly aligned single-world loads are atomic (actually, it
> wouldn't even matter if they weren't atomic because the test is just
> 'is the value != 0').
>
> > That program has a race condition under POSIX pthreads and
> > under C++0x, and according to either standard, a program with a race
> > condition has undefined behavior. Volatile does nothing to change
> > that.
>
> A 'race condition' is defined as 'code whose effects change, depending
> on the order in which several threads do specific things, but without
> any ordering explicitly imposed'. And there is no 'race condition' in
> this example.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
The final draft of C++0x
1.10 Multi-threaded executions and data races / 14
[quote]
The execution of a program contains a data race if it contains two
conflicting actions in different threads,
at least one of which is not atomic, and neither happens before the
other. Any such data race results in
undefined behavior.
[/quote]

Thus, your code has undefined behavior under C++0x.

I'm trying to find the equivalent wording from POSIX pthreads
standard. Everyone says it's there, but I can't find it. Anyone know
of the citation for this? Here's what I have offhand:

http://pubs.opengroup.org/onlinepubs/009604499/xrat/xbd_chap04.html
[quote]
IEEE Std 1003.1-2001 also does not make a formal specification of the
partial ordering in time that the functions can impose, as that is
implied in the description of the semantics of each function. It
simply states that the programmer has to ensure that modifications do
not occur "simultaneously" with other access to a memory location.
[/quote]

http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/mm.html
[quote]
These produce unexpected results in the presence of data races. But
given the pthreads approach of outlawing data races, they appear
benign, and can improve performance.
[/quote]

To repeat, your code has undefined behavior, and volatile does nothing
(portably) to fix it.

With that out of the way, let me try and reply to some of your finer
points. Let me reproduce part of your post here:

> For the situation I gave (which is virtually identical to 'the
> situation'), this program will execute the while-loop until the change
> to variable done by one thread (or 'the signal handler') is noticed by
> the thread executing the loop.

A signal handler is vastly different than another thread of execution.
A signal handler executing in /this/ thread does not have the same
problems that a write from a /different/ thread may have. In practical
terms, there's all sorts of hardware optimizations and such that come
into play, such as the infamous DEC Alpha split cache.

However, what is important is that your code violates the relevant
standards, and the relevant standards say that your code has undefined
behavior. Thus, I would not write code like that, /especially/ when
writing it the correct way is just as easy.

> The behaviours isn't defined by any of
> the possibly applicable standards because these are meant to be less
> restrictive wrt platforms which can be used to implement
> them.

I'm trying to parse that English, but I'm failing. What are you trying
to say? If we're talking about portable conforming code, then we must
be discussing that in the context of some standard. To repreat, if
you're talking about writing code to a particular implementation and
its (probably undocumented) guarantees, then meh. If there is no
reasonable portable alternative, then that can be reasonable. Inter-
thread communication is not such an example - it is possible to do
that portably, and thus it should be done portably.

For the above C code, the only relevant portable standards are POSIX
pthreads, C++0x (and the upcoming C standard which will largely copy
the C++0x memory model), and the win32 threading standard. Under
pthreads and C++0x, your code has undefined behavior. (Your code might
not have undefined behavior under win32, but that's a whole separate
other discussion.)

> Especially, sig_atomic_t is a typedef name and this implies that
> some native type which can safely be used in place of sig_atomic_t
> must exist. Practically, this type will be 'int' because int is
> supposed to be 'the most natural integer type for the architecture'
> and correctly aligned single-world loads are atomic (actually, it
> wouldn't even matter if they weren't atomic because the test is just
> 'is the value != 0').

So many things wrong here.

You are assuming too many things. You are assuming that properly
aligned "int" accesses is atomic. You are assuming that atomic
accesses are all you need for correct threading code, which is this is
incorrect; you need correct visibility guarantees. Hell, sig_atomic_t
is guaranteed to hold at least 256 bits, which is far less than what
int is guaranteed to be able to hold, which begs why you think that
int accesses are obviously going to be atomic.

Also, these assumptions need not be made. Just throw on proper
locking, and it will work without all of this contrived and flaky
reasoning.

Also, to emphasize what I said earlier, even if I were to
hypothetically grant all of that, that int accesses will be atomic,
and volatile will guarantee that a compiler will not "optimize" away
loads and stores to objects of fundamental type, you're still screwed.
The compiler is still free to reorder non-volatile loads and stores
with each other. The hardware is still free to do single-pipeline
reordering. The hardware is still free to do the normal operating
procedure and /not/ flush caches. I would not be surprised if there
was a system out there in which your code (reproduced below) would
deadlock.

    //global:
    static volatile int b;

    //some function:
    while (!b);
    printf("b is now %d\n", b);

In that code, there is nothing to flush the caches. It is possible
that the CPU will just endlessly do a load of b which will be
satisfied by a core local cache, never seeing the new value from main
memory.

(Arguably, if you are on a system with timeslicing so that you know
that threads will be taken off the core at regular intervals, and thus
their caches invalidated, then the deadlock won't happen - you'll just
exhaust the rest of your timeslice. However, that reasoning used like
half a dozen implementation assumptions, all in a single sentence. The
point is that such assumptions are just bad, and you should not do
that.)

To build off the previous point, the most important point is that it's
formally undefined behavior. That means compiler writers and chip
makers will not go out of their way to keep it working. In fact, they
won't even care. Even if your hacks work now, tomorrow when they
produce some new chip, or some new optimization, your code can break.
If you enjoy cowboy coding and writing ticking time bombs of program
failure, then please continue to do so. Just do not so on my team, or
on any software that I might ever use (etc. etc.).

[toc] | [prev] | [next] | [standalone]

#742

Joshua Maurice <joshuamaurice@gmail.com> writes:
> On Jun 3, 7:19 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

[...]

>> >>         static int b;
>>
>> >>         while (!b);
>> >>         printf("b is now %d\n", b);

[...]

>> > That program has a race condition under POSIX pthreads and
>> > under C++0x, and according to either standard, a program with a race
>> > condition has undefined behavior. Volatile does nothing to change
>> > that.
>>
>> A 'race condition' is defined as 'code whose effects change, depending
>> on the order in which several threads do specific things, but without
>> any ordering explicitly imposed'. And there is no 'race condition' in
>> this example.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> The final draft of C++0x
> 1.10 Multi-threaded executions and data races / 14
> [quote]
> The execution of a program contains a data race if it contains two
> conflicting actions in different threads,
> at least one of which is not atomic, and neither happens before the
> other. Any such data race results in
> undefined behavior.
> [/quote]
>
> Thus, your code has undefined behavior under C++0x.

There are no 'two conflicting actions' in this example.

[...]

> To repeat, your code has undefined behavior, and volatile does nothing
> (portably) to fix it.

To repeat: The purpose of volatile is to inform an ANSI/ISO compliant
C-compiler that 'object accesses' should not be regarded as idempotent
despite this cannot be concluded from the code itself. In the example
I gave, this means the compiler is supposed to actually emit code for
a loop which tests the value of the object repeatedly. 

But actually, I'm not in the mood of trying to explain this to people
who are too convinced to be omniscient to listen. Gehabt euch wohl,
Gevatter, and please don't write any multithreaded code for as long as
you don't even understand what 'a race condition' actually is ...

[toc] | [prev] | [next] | [standalone]

#743

On Jun 5, 8:46 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> > On Jun 3, 7:19 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> >> >>         static int b;
>
> >> >>         while (!b);
> >> >>         printf("b is now %d\n", b);

[...]

> >> > That program has a race condition under POSIX pthreads and
> >> > under C++0x, and according to either standard, a program with a race
> >> > condition has undefined behavior. Volatile does nothing to change
> >> > that.
>
> >> A 'race condition' is defined as 'code whose effects change, depending
> >> on the order in which several threads do specific things, but without
> >> any ordering explicitly imposed'. And there is no 'race condition' in
> >> this example.
>
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> > The final draft of C++0x
> > 1.10 Multi-threaded executions and data races / 14
> > [quote]
> > The execution of a program contains a data race if it contains two
> > conflicting actions in different threads,
> > at least one of which is not atomic, and neither happens before the
> > other. Any such data race results in
> > undefined behavior.
> > [/quote]
>
> > Thus, your code has undefined behavior under C++0x.
>
> There are no 'two conflicting actions' in this example.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
The final draft of C++0x
1.10 Multi-threaded executions and data races / 3
[quote]
Two expression evaluations conflict if one of them modifies a memory
location and the other one accesses or
modifies the same memory location.
[/quote]

That is, your two memory accesses to the volatile object are
"conflicting memory accesses" (1.10 / 3). Neither one is atomic (see:
std::atomic). There is no happens-before relationship between the two
memory accesses. Thus the code has a data race and results in
undefined behavior (1.10 / 14).

Also, I just scanned the entire n3092 for all mentions of the word
"volatile", and not a single one alters the above reasoning.

> > To repeat, your code has undefined behavior, and volatile does nothing
> > (portably) to fix it.
>
> To repeat: The purpose of volatile is to inform an ANSI/ISO compliant
> C-compiler that 'object accesses' should not be regarded as idempotent
> despite this cannot be concluded from the code itself. In the example
> I gave, this means the compiler is supposed to actually emit code for
> a loop which tests the value of the object repeatedly.
>
> But actually, I'm not in the mood of trying to explain this to people
> who are too convinced to be omniscient to listen. Gehabt euch wohl,
> Gevatter, and please don't write any multithreaded code for as long as
> you don't even understand what 'a race condition' actually is ...

http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html

Please let the volatile-threading urban myth die the ignoble death it
deserves.

[toc] | [prev] | [next] | [standalone]

#744

Joshua Maurice <joshuamaurice@gmail.com> writes:
> On Jun 5, 8:46 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> Joshua Maurice <joshuamaur...@gmail.com> writes:
>> > On Jun 3, 7:19 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> >> >>         static int b;
>>
>> >> >>         while (!b);
>> >> >>         printf("b is now %d\n", b);
>
> [...]
>
>> >> > That program has a race condition under POSIX pthreads and
>> >> > under C++0x, and according to either standard, a program with a race
>> >> > condition has undefined behavior. Volatile does nothing to change
>> >> > that.
>>
>> >> A 'race condition' is defined as 'code whose effects change, depending
>> >> on the order in which several threads do specific things, but without
>> >> any ordering explicitly imposed'. And there is no 'race condition' in
>> >> this example.
>>
>> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
>> > The final draft of C++0x
>> > 1.10 Multi-threaded executions and data races / 14
>> > [quote]
>> > The execution of a program contains a data race if it contains two
>> > conflicting actions in different threads,
>> > at least one of which is not atomic, and neither happens before the
>> > other. Any such data race results in
>> > undefined behavior.
>> > [/quote]
>>
>> > Thus, your code has undefined behavior under C++0x.
>>
>> There are no 'two conflicting actions' in this example.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> The final draft of C++0x
> 1.10 Multi-threaded executions and data races / 3
> [quote]
> Two expression evaluations conflict if one of them modifies a memory
> location and the other one accesses or
> modifies the same memory location.
> [/quote]
>
> That is, your two memory accesses to the volatile object are
> "conflicting memory accesses"

This is that some C++ 'draft standard' exists which happens to
contradict some parts of the C-standard and contains a practically
pretty useless definition of 'race conditions'. I admit that I wasn't
aware of that. The behaviour is also undefined according to the
UNIX(*) standard, though, cf

	Applications shall ensure that access to any memory location
	by more than one thread of control (threads or processes) is
	restricted such that no thread of control can read or modify a
	memory location while another thread of control may be
	modifying it.
        http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html,
	4.11

> (1.10 / 3). Neither one is atomic

What is or isn't an atomic operation on some kind of computer is not
defined by 'C++ draft standards' (or the UNIX(*)-standard, FWIW). And
code doesn't execute on C++ draft standards (or the UNIX(*)-standard),
either. In this particular case, I stated the 'platform restrictions'
this example relied on (atomicity of memory operations on properly
aligned single-word values and a compiler which aligns these values
properly if it can chose their placement) and I also tried to point
out that, for all pratical purposes, these two assumption are
generally true. I'd happily hear about situations where they are not,
although 'portable to everything Linux runs on' is entirely sufficient
for all my needs at the moment (and likely, forever).

But all of this is an excursion into theory which is completely
besides the point, which happened to be the meaning of volatile.

[...]

> Please let the volatile-threading urban myth die the ignoble death it
> deserves.

And despite your stubborn refusal to let go of the 'volatile-threading
urban myth', volatile still isn't related to 'threading' at all and
was never meant to be: It is supposed to inform a ANSI/ISO complaint C
compiler (did I mention that I care about as little for C++ compilers
as I do for C++ draft standards?) that 'accessing an object' (as
opposed to modifiying an object) should be regarded as a side effect,
instead of as idempotent.

BTW, I hope I'll get the filtering setup correctly this time.

[toc] | [prev] | [next] | [standalone]

#745

On Jun 6, 5:35 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> > On Jun 5, 8:46 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> >> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >> > On Jun 3, 7:19 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> >> >> >>         static int b;
>
> >> >> >>         while (!b);
> >> >> >>         printf("b is now %d\n", b);
>
> > [...]
>
> >> >> > That program has a race condition under POSIX pthreads and
> >> >> > under C++0x, and according to either standard, a program with a race
> >> >> > condition has undefined behavior. Volatile does nothing to change
> >> >> > that.
>
> >> >> A 'race condition' is defined as 'code whose effects change, depending
> >> >> on the order in which several threads do specific things, but without
> >> >> any ordering explicitly imposed'. And there is no 'race condition' in
> >> >> this example.
>
> >> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> >> > The final draft of C++0x
> >> > 1.10 Multi-threaded executions and data races / 14
> >> > [quote]
> >> > The execution of a program contains a data race if it contains two
> >> > conflicting actions in different threads,
> >> > at least one of which is not atomic, and neither happens before the
> >> > other. Any such data race results in
> >> > undefined behavior.
> >> > [/quote]
>
> >> > Thus, your code has undefined behavior under C++0x.
>
> >> There are no 'two conflicting actions' in this example.
>
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> > The final draft of C++0x
> > 1.10 Multi-threaded executions and data races / 3
> > [quote]
> > Two expression evaluations conflict if one of them modifies a memory
> > location and the other one accesses or
> > modifies the same memory location.
> > [/quote]
>
> > That is, your two memory accesses to the volatile object are
> > "conflicting memory accesses"
>
> This is that some C++ 'draft standard' exists which happens to
> contradict some parts of the C-standard and contains a practically
> pretty useless definition of 'race conditions'. I admit that I wasn't
> aware of that. The behaviour is also undefined according to the
> UNIX(*) standard, though, cf
>
>         Applications shall ensure that access to any memory location
>         by more than one thread of control (threads or processes) is
>         restricted such that no thread of control can read or modify a
>         memory location while another thread of control may be
>         modifying it.
>        http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html,
>         4.11
>
> > (1.10 / 3). Neither one is atomic
>
> What is or isn't an atomic operation on some kind of computer is not
> defined by 'C++ draft standards' (or the UNIX(*)-standard, FWIW). And
> code doesn't execute on C++ draft standards (or the UNIX(*)-standard),
> either. In this particular case, I stated the 'platform restrictions'
> this example relied on (atomicity of memory operations on properly
> aligned single-word values and a compiler which aligns these values
> properly if it can chose their placement) and I also tried to point
> out that, for all pratical purposes, these two assumption are
> generally true. I'd happily hear about situations where they are not,
> although 'portable to everything Linux runs on' is entirely sufficient
> for all my needs at the moment (and likely, forever).
>
> But all of this is an excursion into theory which is completely
> besides the point, which happened to be the meaning of volatile.
>
> [...]
>
> > Please let the volatile-threading urban myth die the ignoble death it
> > deserves.
>
> And despite your stubborn refusal to let go of the 'volatile-threading
> urban myth', volatile still isn't related to 'threading' at all and
> was never meant to be: It is supposed to inform a ANSI/ISO complaint C
> compiler (did I mention that I care about as little for C++ compilers
> as I do for C++ draft standards?) that 'accessing an object' (as
> opposed to modifiying an object) should be regarded as a side effect,
> instead of as idempotent.

The upcoming C standard is going to largely copy these semantics. The
semantics have been developed through close work with the C standards
committee and the POSIX people, in order to achieve as best as they
can conformance and uniformity.

> BTW, I hope I'll get the filtering setup correctly this time.

Is that a more polite form of "plonk"?

[toc] | [prev] | [next] | [standalone]

#746

On Jun 6, 5:35 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
> > The final draft of C++0x
> > 1.10 Multi-threaded executions and data races / 3
[...]
> > (1.10 / 3). Neither one is atomic
>
> What is or isn't an atomic operation on some kind of computer is not
> defined by 'C++ draft standards' (or the UNIX(*)-standard, FWIW).

Sorry for the second post. Missed this minor point. It in fact does
define what is atomic or not. In context, "atomic" means accesses of
type std::atomic. In context, "atomic" does not mean what operations
merely happen to be implemented / implementable as a single assembly
load or a single assembly store.

[toc] | [prev] | [next] | [standalone]

#747

On 06/ 7/11 12:35 AM, Rainer Weikusat wrote:
>
> And despite your stubborn refusal to let go of the 'volatile-threading
> urban myth', volatile still isn't related to 'threading' at all and
> was never meant to be: It is supposed to inform a ANSI/ISO complaint C
> compiler (did I mention that I care about as little for C++ compilers
> as I do for C++ draft standards?) that 'accessing an object' (as
> opposed to modifiying an object) should be regarded as a side effect,
> instead of as idempotent.

Luckily for the rest of us, the ISO C committee does care about C++ 
draft standards:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1508.htm

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#753

Ian Collins <ian-news@hotmail.com> writes:
> On 06/ 7/11 12:35 AM, Rainer Weikusat wrote:
>> And despite your stubborn refusal to let go of the 'volatile-threading
>> urban myth', volatile still isn't related to 'threading' at all and
>> was never meant to be: It is supposed to inform a ANSI/ISO complaint C
>> compiler (did I mention that I care about as little for C++ compilers
>> as I do for C++ draft standards?) that 'accessing an object' (as
>> opposed to modifiying an object) should be regarded as a side effect,
>> instead of as idempotent.
>
> Luckily for the rest of us, the ISO C committee does care about C++
> draft standards:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1508.htm

Could you perhaps enlighten me what your posting is supposed to
communicate? It is not really surprising that 'interoperability
between future versions of C and future versions of C++' is a concern
for the respective ISO committees. Also, the retroactive speculational
reasoning wrt 'atomicity of object accesses', namely 'possibly, some
ISO committee will standardize a specific way of working with/ using
atomic objects in future' => whatever isn't identical to this hypothetical
future language change now cannot be atomic' remains as invalid as ever.

[toc] | [prev] | [next] | [standalone]

#761

On 06/ 8/11 12:29 AM, Rainer Weikusat wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 06/ 7/11 12:35 AM, Rainer Weikusat wrote:
>>> And despite your stubborn refusal to let go of the 'volatile-threading
>>> urban myth', volatile still isn't related to 'threading' at all and
>>> was never meant to be: It is supposed to inform a ANSI/ISO complaint C
>>> compiler (did I mention that I care about as little for C++ compilers
>>> as I do for C++ draft standards?) that 'accessing an object' (as
>>> opposed to modifiying an object) should be regarded as a side effect,
>>> instead of as idempotent.
>>
>> Luckily for the rest of us, the ISO C committee does care about C++
>> draft standards:
>>
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1508.htm
>
> Could you perhaps enlighten me what your posting is supposed to
> communicate?

That your head in the sand attitude isn't shared but those who are 
shaping the future of C.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#769

Ian Collins <ian-news@hotmail.com> writes:
> On 06/ 8/11 12:29 AM, Rainer Weikusat wrote:
>> Ian Collins<ian-news@hotmail.com>  writes:
>>> On 06/ 7/11 12:35 AM, Rainer Weikusat wrote:
>>>> And despite your stubborn refusal to let go of the 'volatile-threading
>>>> urban myth', volatile still isn't related to 'threading' at all and
>>>> was never meant to be: It is supposed to inform a ANSI/ISO complaint C
>>>> compiler (did I mention that I care about as little for C++ compilers
>>>> as I do for C++ draft standards?) that 'accessing an object' (as
>>>> opposed to modifiying an object) should be regarded as a side effect,
>>>> instead of as idempotent.
>>>
>>> Luckily for the rest of us, the ISO C committee does care about C++
>>> draft standards:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1508.htm
>>
>> Could you perhaps enlighten me what your posting is supposed to
>> communicate?
>
> That your head in the sand attitude isn't shared but those who are
> shaping the future of C.

How did you manage to miss

	It is not really surprising that 'interoperability
	between future versions of C and future versions of C++' is a concern
	for the respective ISO committees.

?

I don't sit on any standards commitees and consequently, 'draft
standards' are no concern of mine and neither do I use C++ and
consequently, C++-compilers, -standards and especially, draft
standards are also no concern of mine.

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web