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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#834

Joshua Maurice <joshuamaurice@gmail.com> writes:
>On Jun 19, 5:35=A0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> Michael Press <rub...@pacbell.net> writes:
>> > In article
>> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
>> > =A0Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>
>> > [...]
>>
>> > Not knowing any of the fine points of the discussion
>> > and basing my assessment upon other cues, I think you
>> > must have the right of it.
>>
>> Insofar all kinds of 'paper decrees' are naively considered, I would
>> agree with this presumption. Insofar actual multi-threaded programming
>> of current (SMP) hardware both in applications and in OS kernels is
>> concerned, I claim that this isn't (and was never) done according to
>> some set of possible future C and C++ language standards.
>>
>> >> (I'm not sure why I'm even responding at this point.
>>
>> Rest assured that I won't see it :->.
>
>Well, for the benefit of others, I will simply point out the straw man
>that you are attacking. In nearly every post in this thread, I have
>cited not merely only future C and C++ standards. I have also cited
>the POSIX pthreads standard, every C expert, every C++ expert, every C
>and C++ compiler writer, and the demonstrable facts about past and
>current compilers, as the basis of my claim that you're doing it
>wrong.

Then again, some of us who have participated in this thread have written
entire operating systems (inherently and highly-grained multithreaded applications
to be sure) in C and C++ without using pthreads, windows threads, or any
other synchronization technology known to the compiler.  I've done four
operating systems (1 in a language called SPRITE, two in C and one in C++)
and two hypervisors (both in C++) over the last 30 years.    One typically
uses external assembler functions (or inline asm when available) to achieve
things that aren't part of the language definition (e.g. memory barriers,
atomic access semantics), but the compilers themselves (PCC, SVR4 CCS, Irix C,
Windows C++, gnu compiler collection) all do the _right thing_ with respect to
moving code around sequence points.   You may be correct in that the standard
allows the compiler to be looser with respect to such movement, but in
practice the implementations of the standard are more rigid.

scott

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

#835

scott@slp53.sl.home (Scott Lurndal) writes:
> Joshua Maurice <joshuamaurice@gmail.com> writes:
>>On Jun 19, 5:35=A0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>> Michael Press <rub...@pacbell.net> writes:
>>> > In article
>>> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
>>> > =A0Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>>
>>> > [...]
>>>
>>> > Not knowing any of the fine points of the discussion
>>> > and basing my assessment upon other cues, I think you
>>> > must have the right of it.
>>>
>>> Insofar all kinds of 'paper decrees' are naively considered, I would
>>> agree with this presumption. Insofar actual multi-threaded programming
>>> of current (SMP) hardware both in applications and in OS kernels is
>>> concerned, I claim that this isn't (and was never) done according to
>>> some set of possible future C and C++ language standards.
>>>
>>> >> (I'm not sure why I'm even responding at this point.
>>>
>>> Rest assured that I won't see it :->.
>>
>>Well, for the benefit of others, I will simply point out the straw man
>>that you are attacking. In nearly every post in this thread, I have
>>cited not merely only future C and C++ standards. I have also cited
>>the POSIX pthreads standard, every C expert, every C++ expert, every C
>>and C++ compiler writer, and the demonstrable facts about past and
>>current compilers, as the basis of my claim that you're doing it
>>wrong.
>
> Then again, some of us who have participated in this thread have
> written entire operating systems (inherently and highly-grained
> multithreaded applications to be sure) in C and C++ without using
> pthreads, windows threads, or any other synchronization technology
> known to the compiler.

[...]

> the compilers themselves (PCC, SVR4 CCS, Irix C,Windows C++, gnu
> compiler collection) all do the _right thing_ with respect to
> moving code around sequence points.

This was actually about a different issue, namely, concurrent access
to the same memory location. The UNIX(*)-standard doesn't define a
behaviour for the situation where one thread of control writes to a
memory location another thread of control also writes to or reads from
and the behaviour in case of concurrent read accesses is
implementation-defined. This is, of course, practically fairly
irrelevant since mutual exclusion algorithms are (AFAIK) always based
on such concurrent accesses provided in some hardware-specific way
(which is why hardware-independent standards are silent on this). I
was using an example where I would use volatile in a multi-threaded
program which assumed that one thread was repeatedly reading from a
particular memory location with another eventually writing to it, IOW,
a very simplistic example of a spin lock. In my opinion, the volatile
is needed in this case in order to instruct the compiler to actually
generate code for those repeated reads. Mr Maurice, OTOH, seems to
assume that I believe that this volatile would 'somehow' cure the in
his opinion absolutely lethal disease 'standard XYZ does not define a
behaviour for that' because some people known to him were erronously
convinced that 'volatile' was actually meant to be used for
inter-thread synchronization in some completely inexplainable way.
Or so.

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

#839

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Joshua Maurice <joshuamaurice@gmail.com> writes:
>>>On Jun 19, 5:35=A0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>>> Michael Press <rub...@pacbell.net> writes:
>>>> > In article
>>>> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
>>>> > =A0Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>>>
>>>> > [...]
>>>>
>>>> > Not knowing any of the fine points of the discussion
>>>> > and basing my assessment upon other cues, I think you
>>>> > must have the right of it.
>>>>
>>>> Insofar all kinds of 'paper decrees' are naively considered, I would
>>>> agree with this presumption. Insofar actual multi-threaded programming
>>>> of current (SMP) hardware both in applications and in OS kernels is
>>>> concerned, I claim that this isn't (and was never) done according to
>>>> some set of possible future C and C++ language standards.
>>>>
>>>> >> (I'm not sure why I'm even responding at this point.
>>>>
>>>> Rest assured that I won't see it :->.
>>>
>>>Well, for the benefit of others, I will simply point out the straw man
>>>that you are attacking. In nearly every post in this thread, I have
>>>cited not merely only future C and C++ standards. I have also cited
>>>the POSIX pthreads standard, every C expert, every C++ expert, every C
>>>and C++ compiler writer, and the demonstrable facts about past and
>>>current compilers, as the basis of my claim that you're doing it
>>>wrong.
>>
>> Then again, some of us who have participated in this thread have
>> written entire operating systems (inherently and highly-grained
>> multithreaded applications to be sure) in C and C++ without using
>> pthreads, windows threads, or any other synchronization technology
>> known to the compiler.
>
>[...]
>
>> the compilers themselves (PCC, SVR4 CCS, Irix C,Windows C++, gnu
>> compiler collection) all do the _right thing_ with respect to
>> moving code around sequence points.
>
>This was actually about a different issue, namely, concurrent access
>to the same memory location. The UNIX(*)-standard doesn't define a
>behaviour for the situation where one thread of control writes to a
>memory location another thread of control also writes to or reads from
>and the behaviour in case of concurrent read accesses is
>implementation-defined.

True.  Yet for inherenly non-portable purposes such as operating
systems or other bare-metal code, the 'implementation-defined'
behavior is at least well defined.

There is no portable use of the volatile type qualifier, even
with signals (since sig_atomic_t is the defined type to use there).

That's not to say, however, that I haven't used the volatile
type qualifier in the past in pthreaded app code;  while non-portable,
both the solaris and gcc compilers have done as expected with
respect to optimization of code which used the results of an
expression containing variables with volatile qualifiers.

Consider the case where you exit a loop when another thread
sets a boolean variable to false.   Marking the boolean
variable declaration as volatile will prevent the compiler
from turning the loop into a while (1) loop.   Perhaps not
portable as guaranteed by the standard, but portable enough.

> This is, of course, practically fairly
>irrelevant since mutual exclusion algorithms are (AFAIK) always based
>on such concurrent accesses provided in some hardware-specific way
>(which is why hardware-independent standards are silent on this). I
>was using an example where I would use volatile in a multi-threaded
>program which assumed that one thread was repeatedly reading from a
>particular memory location with another eventually writing to it, IOW,
>a very simplistic example of a spin lock. In my opinion, the volatile
>is needed in this case in order to instruct the compiler to actually
>generate code for those repeated reads.

  I do believe that one should use the volatile in this case.

> Mr Maurice, OTOH, seems to
>assume that I believe that this volatile would 'somehow' cure the in
>his opinion absolutely lethal disease 'standard XYZ does not define a
>behaviour for that' because some people known to him were erronously
>convinced that 'volatile' was actually meant to be used for
>inter-thread synchronization in some completely inexplainable way.

Talking at cross-purposes is a common on usenet.

s

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

#840

On Jun 21, 10:30 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> Rainer Weikusat <rweiku...@mssgmbh.com> writes:
> > This is, of course, practically fairly
> >irrelevant since mutual exclusion algorithms are (AFAIK) always based
> >on such concurrent accesses provided in some hardware-specific way
> >(which is why hardware-independent standards are silent on this). I
> >was using an example where I would use volatile in a multi-threaded
> >program which assumed that one thread was repeatedly reading from a
> >particular memory location with another eventually writing to it, IOW,
> >a very simplistic example of a spin lock. In my opinion, the volatile
> >is needed in this case in order to instruct the compiler to actually
> >generate code for those repeated reads.
>
>   I do believe that one should use the volatile in this case.
>
> > Mr Maurice, OTOH, seems to
> >assume that I believe that this volatile would 'somehow' cure the in
> >his opinion absolutely lethal disease 'standard XYZ does not define a
> >behaviour for that' because some people known to him were erronously
> >convinced that 'volatile' was actually meant to be used for
> >inter-thread synchronization in some completely inexplainable way.
>
> Talking at cross-purposes is a common on usenet.

Indeed. I've been trying to stress /portable/ in every post. I'm sure
you could hack it up with volatile, relying on specific implementation
guarantees, or relying on current undocumented facts of the
implementation. The basic point of contention is clear, to me at
least. I claim that you should avoid volatile wherever possible, and
instead preferring portable constructs. Sometimes you may need to use
volatile. Preferably, such non-portable code should be kept hidden
behind a nice abstraction (like an inline function), with a fair
amount of documentation and comments, and not liberally sprinkled
throughout the code.

For example, a
  while (thread_shared_variable)
    {}
loop. Preferably, the variable should not be made volatile. I must
politely disagree with both of you. You should use a suitable
abstraction, preferably one that other people would recognize. Make
the variable of a magic type which is documented as guaranteed to not
be optimized away, if that's what you want. Then, in the
implementation, maybe implement it with volatile, in order to keep the
hacks out of the main code. Because it is likely a hack, and should be
kept as isolated as possible, and as refactorable as possible.

That I think is the crucial distinction. I want to call volatile a
hack which may work in practice on some implementations, but it is
definitely not guaranteed to do anything productive by the C standard.
(Well, actually I disagree with you on one minor point - volatile
actually is portably useful for setjump longjump, or so I've heard.)
Rainer Weikusat wants to say that volatile has useful, predictable,
properties guaranteed by the C standard, and that is incorrect.

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

#836

On Jun 20, 9:22 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >On Jun 19, 5:35=A0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> >> Michael Press <rub...@pacbell.net> writes:
> >> > In article
> >> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
> >> > =A0Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> >> > [...]
>
> >> > Not knowing any of the fine points of the discussion
> >> > and basing my assessment upon other cues, I think you
> >> > must have the right of it.
>
> >> Insofar all kinds of 'paper decrees' are naively considered, I would
> >> agree with this presumption. Insofar actual multi-threaded programming
> >> of current (SMP) hardware both in applications and in OS kernels is
> >> concerned, I claim that this isn't (and was never) done according to
> >> some set of possible future C and C++ language standards.
>
> >> >> (I'm not sure why I'm even responding at this point.
>
> >> Rest assured that I won't see it :->.
>
> >Well, for the benefit of others, I will simply point out the straw man
> >that you are attacking. In nearly every post in this thread, I have
> >cited not merely only future C and C++ standards. I have also cited
> >the POSIX pthreads standard, every C expert, every C++ expert, every C
> >and C++ compiler writer, and the demonstrable facts about past and
> >current compilers, as the basis of my claim that you're doing it
> >wrong.
>
> Then again, some of us who have participated in this thread have written
> entire operating systems (inherently and highly-grained multithreaded applications
> to be sure) in C and C++ without using pthreads, windows threads, or any
> other synchronization technology known to the compiler.  I've done four
> operating systems (1 in a language called SPRITE, two in C and one in C++)
> and two hypervisors (both in C++) over the last 30 years.    One typically
> uses external assembler functions (or inline asm when available) to achieve
> things that aren't part of the language definition (e.g. memory barriers,
> atomic access semantics), but the compilers themselves (PCC, SVR4 CCS, Irix C,
> Windows C++, gnu compiler collection) all do the _right thing_ with respect to
> moving code around sequence points.   You may be correct in that the standard
> allows the compiler to be looser with respect to such movement, but in
> practice the implementations of the standard are more rigid.

Two comments.

First, I was talking about volatile being useless /portably/, as in
guaranteed by any relevant portable respected standard, for uses which
Rainer Weikusat suggests. I'm sure plenty of people have either hacked
it with volatile and got lucky, and/or wrote code to a specific
implementation and its specific guarantees.

Second, I disagree that the common implementations of C are "as rigid"
as you make them out to be. in practice, if the compiler can inline
the function, then it can do wonderful analysis and move all sorts of
code around. Also, with implementations with link time code
generation, this can happen even for functions which aren't inline-
able in the current translation unit. So of course with an external
function which cannot be inlined, the compiler will take a
conservative approach, as will the linker.

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

#838

Joshua Maurice <joshuamaurice@gmail.com> writes:
>On Jun 20, 9:22=A0am, sc...@slp53.sl.home (Scott Lurndal) wrote:
>> Joshua Maurice <joshuamaur...@gmail.com> writes:
>> >On Jun 19, 5:35=3DA0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> >> Michael Press <rub...@pacbell.net> writes:
>> >> > In article
>> >> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
>> >> > =3DA0Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>
>> >> > [...]
>>
>> >> > Not knowing any of the fine points of the discussion
>> >> > and basing my assessment upon other cues, I think you
>> >> > must have the right of it.
>>
>> >> Insofar all kinds of 'paper decrees' are naively considered, I would
>> >> agree with this presumption. Insofar actual multi-threaded programming
>> >> of current (SMP) hardware both in applications and in OS kernels is
>> >> concerned, I claim that this isn't (and was never) done according to
>> >> some set of possible future C and C++ language standards.
>>
>> >> >> (I'm not sure why I'm even responding at this point.
>>
>> >> Rest assured that I won't see it :->.
>>
>> >Well, for the benefit of others, I will simply point out the straw man
>> >that you are attacking. In nearly every post in this thread, I have
>> >cited not merely only future C and C++ standards. I have also cited
>> >the POSIX pthreads standard, every C expert, every C++ expert, every C
>> >and C++ compiler writer, and the demonstrable facts about past and
>> >current compilers, as the basis of my claim that you're doing it
>> >wrong.
>>
>> Then again, some of us who have participated in this thread have written
>> entire operating systems (inherently and highly-grained multithreaded app=
>lications
>> to be sure) in C and C++ without using pthreads, windows threads, or any
>> other synchronization technology known to the compiler. =A0I've done four
>> operating systems (1 in a language called SPRITE, two in C and one in C++=
>)
>> and two hypervisors (both in C++) over the last 30 years. =A0 =A0One typi=
>cally
>> uses external assembler functions (or inline asm when available) to achie=
>ve
>> things that aren't part of the language definition (e.g. memory barriers,
>> atomic access semantics), but the compilers themselves (PCC, SVR4 CCS, Ir=
>ix C,
>> Windows C++, gnu compiler collection) all do the _right thing_ with respe=
>ct to
>> moving code around sequence points. =A0 You may be correct in that the st=
>andard
>> allows the compiler to be looser with respect to such movement, but in
>> practice the implementations of the standard are more rigid.
>
>Two comments.
>
>First, I was talking about volatile being useless /portably/, as in
>guaranteed by any relevant portable respected standard, for uses which
>Rainer Weikusat suggests. I'm sure plenty of people have either hacked
>it with volatile and got lucky, and/or wrote code to a specific
>implementation and its specific guarantees.
>
>Second, I disagree that the common implementations of C are "as rigid"
>as you make them out to be. in practice, if the compiler can inline
>the function, then it can do wonderful analysis and move all sorts of
>code around. Also, with implementations with link time code
>generation, this can happen even for functions which aren't inline-
>able in the current translation unit. So of course with an external
>function which cannot be inlined, the compiler will take a
>conservative approach, as will the linker.

In the most recent hypervisor (supported 256-core guests[*] on 1024-core
systems), we used inline functions heavily.  Very heavily;  for
example:

/**
 * Obtain the lock, spinning if necessary.  See class documentation for
 * algorithm details.
 */
inline void
c_spinlock::lock(void)
{
    __asm__ __volatile__ (
        "\n1:\t"
        "lock; decl %0\n\t"
        "jz  3f\n"
        "2:\n\t"
        "rep; nop\n\t"
        "cmpl $0, %0\n\t"
        "jle  2b\n\t"
        "jmp  1b\n\t"
        "3:\n\t": "=m" (lockval) : : "memory");
}

/**
 * Lock and Disable platform interrupts.  Platform interrupts are first
 * disabled then the lock is aquired.   The prior state of the interrupt
 * enable flag is returned to the caller.
 *
 * @returns  true if interrupts were enabled prior to calling this function.
 */
inline bool
c_spinlock::lock_noint(void)
{
    bool istate = (get_rflags() & RFLAGS_IF);
    ::cli();
    lock();

    return istate;
}

We used the Gnu compiler collection, version 4.

g++ -O2 -mtune=opteron -fPIC -fno-strict-aliasing -mno-red-zone -nostdlib -nostartfiles -Wall
-Werror

While we ran into cases where the processor reordering mattered (and we subsequently
added memory barriers where necessary), we have never encountered a case where the
compiler moved something outside of a critical section.

scott

[*] Most current distributions of linux only support 256 cores due to the
    legacy APIC ID field being eight bits wide.  As intel's X2APIC support
    gets added to RHEL/SLES/Windows Server, the hypervisor will support larger
    guests (note that VMware etc. only recently have supported 8 core guests,
    due to the difficulties (technical and performance) in gang-scheduling).

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

#832

On Jun 19, 1:43 am, Michael Press <rub...@pacbell.net> wrote:
> In article
> <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
>  Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> [...]
>
> Not knowing any of the fine points of the discussion
> and basing my assessment upon other cues, I think you
> must have the right of it.
>
> > (I'm not sure why I'm even responding at this point. Oh well. Duty
> > calls.
> >http://xkcd.com/386/
> > )
>
> And upon that assessment going to xkcd is as using
> a wood chisel to open a locked desk drawer: neither
> is at their best when you finish, and what have you
> accomplished?

I'm not following the locked drawer analogy. Linking to it was never
intended as a form of argument or persuasion.

What has it accomplished? It made me laugh, and perhaps it did the
same for others.

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

#842

In article 
<787feba6-03f6-4382-b891-0219ab340a45@l2g2000prg.googlegroups.com>,
 Joshua Maurice <joshuamaurice@gmail.com> wrote:

> On Jun 19, 1:43 am, Michael Press <rub...@pacbell.net> wrote:
> > In article
> > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>,
> >  Joshua Maurice <joshuamaur...@gmail.com> wrote:
> >
> > [...]
> >
> > Not knowing any of the fine points of the discussion
> > and basing my assessment upon other cues, I think you
> > must have the right of it.
> >
> > > (I'm not sure why I'm even responding at this point. Oh well. Duty
> > > calls.
> > >http://xkcd.com/386/
> > > )
> >
> > And upon that assessment going to xkcd is as using
> > a wood chisel to open a locked desk drawer: neither
> > is at their best when you finish, and what have you
> > accomplished?
> 
> I'm not following the locked drawer analogy. 

It is not important enough to explain. Ignore it.

> Linking to it was never
> intended as a form of argument or persuasion.

I took it that way and continue to. 

> What has it accomplished? It made me laugh, and perhaps it did the
> same for others.

It is not as funny, or not funny at all when you point at it
to piggy-back your own message.

-- 
Michael Press

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

#844

On Jun 22, 1:55 am, Michael Press <rub...@pacbell.net> wrote:
> In article
> <787feba6-03f6-4382-b891-0219ab340...@l2g2000prg.googlegroups.com>,
>  Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > Linking to it was never
> > intended as a form of argument or persuasion.
>
> I took it that way and continue to.
>
> > What has it accomplished? It made me laugh, and perhaps it did the
> > same for others.
>
> It is not as funny, or not funny at all when you point at it
> to piggy-back your own message.

Harsh. Sorry for the ill placed self deprecating humor.

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

#727

On Jun 1, 2:54 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> David Schwartz <dav...@webmaster.com> writes:
> > 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?

> > No. Using 'volatile' is neither necessary nor sufficient, so it does
> > nothing but destroy performance.

> This is platform and compiler-dependent.

Well, the 'not necessary' part is not platform or compiler dependent.
It's mandated by POSIX that mutexes be sufficient, therefore
'volatile' cannot be necessary.

> 'volatile' is the ANSI/ISO C
> way to inform a 'translation/ execution' environment that read
> accesses to some object should be regarded as producing  'side
> effects' which they ordinarily wouldn't. This implies that, in the
> strictest sense, whenever two reads from some object might result in
> two values which cannot otherwise be deduced from the past operations
> of the present thread of execution, 'volatile' has to be used, no
> matter how many otherwise unrelated subroutines have been invoked in
> between.

That's simply false. Suppose some new standard specified that
'volatile2' had precisely the same semantics as 'volatile'. Would you
still argue that 'volatile' *has* *to* be used because of what ANSI/
ISO says?

> In practice, it is usually not necessary. There is nothing
> sexy in parroting the 'Gee --- this is way above my head. What a load
> of bullshit!' that marks the outer border of the common Linux kernel
> programmer's understanding of standard C in this respect.

I don't understand what you're saying, but it's never necessary. POSIX
provides alternate mechanisms that are sufficient.

DS

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

#728

On Jun 1, 2:54 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> David Schwartz <dav...@webmaster.com> writes:

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

> > No. Using 'volatile' is neither necessary nor sufficient, so it does
> > nothing but destroy performance.

> This is platform and compiler-dependent.

It's not necessary on any platform with any compiler (since the POSIX
standard says it's not). It's not sufficient on any commonly-used
platform I know of.

DS

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

#729

On 6/1/2011 5:54 PM, Rainer Weikusat wrote:
> [...]There is nothing
> sexy in parroting the 'Gee --- this is way above my head. What a load
> of bullshit!' that marks the outer border of the common Linux kernel
> programmer's understanding of standard C in this respect.

http://www.dilbert.com/strips/comic/2011-06-03/

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#685

On Tue, 31 May 2011, Urs Thuermann wrote:

> Are [...] types [...] atomic when accessed [...] from a signal handler

Look up "sig_atomic_t" in these pages:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_12_01
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html

Again, this is about atomicity, not visibility.

I think you can rely on the flag being immediately visible in the thread 
that was interrupted in a blocking call by the async signal, and thus ran 
the signal handler. I also think that you can rely on the visibility in 
case of synchronous signals, in the victim thread (eg. raise(), 
SIGPIPE/SIGXFSZ on write(), kill() under some circumstances).

lacos

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

#694

On Jun 1, 3:23 pm, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:
> On Tue, 31 May 2011, Urs Thuermann wrote:
> > Are [...] types [...] atomic when accessed [...] from a signal handler
>
> Look up "sig_atomic_t" in these pages:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.htmlhttp://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.htmlhttp://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.h...http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.htmlhttp://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html
>
> Again, this is about atomicity, not visibility.
>
> I think you can rely on the flag being immediately visible in the thread
> that was interrupted in a blocking call by the async signal, and thus ran
> the signal handler. I also think that you can rely on the visibility in
> case of synchronous signals, in the victim thread (eg. raise(),
> SIGPIPE/SIGXFSZ on write(), kill() under some circumstances).

Thank you. I was just about to post something to similar effect, but
I'll add that from my /very/ limited understanding, this is exactly
how you have to do it.

Of course, this begs the question for me, is that sufficient to do
anything "interesting" with a signal handler portably? That is, can
you do anything besides set a flag which is set only once and never
reset? Just curious.

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

#716

On Wed, 1 Jun 2011, Joshua Maurice wrote:

>> I think you can rely on the flag being immediately visible in the 
>> thread that was interrupted in a blocking call by the async signal, and 
>> thus ran the signal handler. I also think that you can rely on the 
>> visibility in case of synchronous signals, in the victim thread (eg. 
>> raise(), SIGPIPE/SIGXFSZ on write(), kill() under some circumstances).
>
> Thank you. I was just about to post something to similar effect, but 
> I'll add that from my /very/ limited understanding, this is exactly how 
> you have to do it.
>
> Of course, this begs the question for me, is that sufficient to do 
> anything "interesting" with a signal handler portably? That is, can you 
> do anything besides set a flag which is set only once and never reset? 
> Just curious.

I did the resetting thing once, and I believe it was okay. The signal 
handler was for SIGCONT, and it set a flag so that the program could make 
an effort to reinitialize a timer, possibly after being stopped for an 
indeterminate time by SIGSTOP.

(Of course one could send a SIGCONT alone, in which case the timer was 
simply reinitialized. If the user had sent such SIGCONTs hundreds of times 
per second, that would have basically killed the timer's purpose; 
otherwise a sole SIGCONT was harmless.)

The program was single threaded, and the only place where SIGCONT could be 
delivered was within a select(). Everything outside select() ran under a 
signal mask that blocked SIGCONT. Resetting the flag happened under the 
protection of this signal mask.

(It would have been nicer to use pselect() instead of sigprocmask() + 
select() + sigprocmask(), but the program was written for SUSv1, and my 
circumstances rewarded portable code having a very small uncovered window 
more than #ifdefs.)

<rant>
I fear signals; I don't want to do anything interesting with them, just 
the bare minimum that's sufficient -- handling SIGINT, SIGTERM if some 
cleanup is needed; SIGCONT if time intervals are involved; masking them 
almost everywhere; never doing more than setting a volatile sig_atomic_t 
etc. Signals are hard, I'm conservative.
</rant>

lacos

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

#718

On Jun 2, 1:54 pm, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:
> On Wed, 1 Jun 2011, Joshua Maurice wrote:
> >> I think you can rely on the flag being immediately visible in the
> >> thread that was interrupted in a blocking call by the async signal, and
> >> thus ran the signal handler. I also think that you can rely on the
> >> visibility in case of synchronous signals, in the victim thread (eg.
> >> raise(), SIGPIPE/SIGXFSZ on write(), kill() under some circumstances).
>
> > Thank you. I was just about to post something to similar effect, but
> > I'll add that from my /very/ limited understanding, this is exactly how
> > you have to do it.
>
> > Of course, this begs the question for me, is that sufficient to do
> > anything "interesting" with a signal handler portably? That is, can you
> > do anything besides set a flag which is set only once and never reset?
> > Just curious.
>
> I did the resetting thing once, and I believe it was okay. The signal
> handler was for SIGCONT, and it set a flag so that the program could make
> an effort to reinitialize a timer, possibly after being stopped for an
> indeterminate time by SIGSTOP.
>
> (Of course one could send a SIGCONT alone, in which case the timer was
> simply reinitialized. If the user had sent such SIGCONTs hundreds of times
> per second, that would have basically killed the timer's purpose;
> otherwise a sole SIGCONT was harmless.)
>
> The program was single threaded, and the only place where SIGCONT could be
> delivered was within a select(). Everything outside select() ran under a
> signal mask that blocked SIGCONT. Resetting the flag happened under the
> protection of this signal mask.
>
> (It would have been nicer to use pselect() instead of sigprocmask() +
> select() + sigprocmask(), but the program was written for SUSv1, and my
> circumstances rewarded portable code having a very small uncovered window
> more than #ifdefs.)
>
> <rant>
> I fear signals; I don't want to do anything interesting with them, just
> the bare minimum that's sufficient -- handling SIGINT, SIGTERM if some
> cleanup is needed; SIGCONT if time intervals are involved; masking them
> almost everywhere; never doing more than setting a volatile sig_atomic_t
> etc. Signals are hard, I'm conservative.
> </rant>

In your example, I'm just wondering if it's possible to have some
races in there. Unless I miss my mark, a program could miss a SIGSTOP
and SIGCONT pair.

Also, just curious how you implemented the gritty details of SIGSTOP.
You set a flag in the signal handler, and then the main code did busy
waiting? Busy waiting with a sleep?

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

#720

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2 Jun 2011, Joshua Maurice wrote:

> On Jun 2, 1:54 pm, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:

>> The signal handler was for SIGCONT, and it set a flag so that the 
>> program could make an effort to reinitialize a timer, possibly after 
>> being stopped for an indeterminate time by SIGSTOP.

>> The program was single threaded, and the only place where SIGCONT could 
>> be delivered was within a select(). Everything outside select() ran 
>> under a signal mask that blocked SIGCONT. Resetting the flag happened 
>> under the protection of this signal mask.

> In your example, I'm just wondering if it's possible to have some races 
> in there. Unless I miss my mark, a program could miss a SIGSTOP and 
> SIGCONT pair.

> Also, just curious how you implemented the gritty details of SIGSTOP. 
> You set a flag in the signal handler, and then the main code did busy 
> waiting? Busy waiting with a sleep?

SIGSTOP can't be caught or ignored; it's delivery is transparent to the 
process. (You can't detect you're not scheduled when you're not being 
scheduled.) So we only need (and can) focus on the delivery of SIGCONT.

Lossage of SIGCONT is avoided like lossage of any other async signal. Now 
assuming pselect(), there are two states in the program: (a) SIGCONT is 
masked and we're outside of pselect(), that is, actively running, not 
blocking on anything; and (b) SIGCONT is unmasked and we're blocked on 
pselect(). On a conformant platform, the transition between these two is 
indivisible by delivery of a signal of interest. (This doesn't hold for 
the sigprocmask() + select() + sigprocmask() triplet, but let's ignore 
that :))

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). Since this state is purely CPU-bound, we'll 
reach the pselect() shortly. Upon entering pselect() (-> state (b)), it 
will be immediately interrupted by the signal handler, and the flag will 
be set. After return from pselect(), the mask will be atomically restored 
(ie. returning to state (a)).

The return status of pselect() is checked in state (a). The flag is 
checked and reset in state (a) [*].

In state (b) we're waiting for data, signals, and a timeout (... which 
could generally be the earliest of many deadlines, maintained in a 
priority queue). The process can be stopped in this state, and when 
continued, pselect() will immedietaly return (after the sighandler 
completes).

[*] even if [p]select() doesn't return -1/EINTR -- on the Alpha OSF1 I had 
access to, if the process was stopped in select() for so long that the 
timeout would have passed, then at SIGCONT the process returned from 
select() with 0, even though the handler was run. This "robust" checking 
won't hurt where select() behaves correctly, and will catch this slight 
error.

Sorry for this wall of text, I hope it's not incorrect. I'm positive I 
mixed up memories about multiple programs.

lacos

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

#721

On Jun 2, 5:49 pm, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:
> On Thu, 2 Jun 2011, Joshua Maurice wrote:
> > On Jun 2, 1:54 pm, "Ersek, Laszlo" <la...@caesar.elte.hu> wrote:
> >> The signal handler was for SIGCONT, and it set a flag so that the
> >> program could make an effort to reinitialize a timer, possibly after
> >> being stopped for an indeterminate time by SIGSTOP.
> >> The program was single threaded, and the only place where SIGCONT could
> >> be delivered was within a select(). Everything outside select() ran
> >> under a signal mask that blocked SIGCONT. Resetting the flag happened
> >> under the protection of this signal mask.
> > In your example, I'm just wondering if it's possible to have some races
> > in there. Unless I miss my mark, a program could miss a SIGSTOP and
> > SIGCONT pair.
> > Also, just curious how you implemented the gritty details of SIGSTOP.
> > You set a flag in the signal handler, and then the main code did busy
> > waiting? Busy waiting with a sleep?
>
> SIGSTOP can't be caught or ignored; it's delivery is transparent to the
> process. (You can't detect you're not scheduled when you're not being
> scheduled.) So we only need (and can) focus on the delivery of SIGCONT.
>
> Lossage of SIGCONT is avoided like lossage of any other async signal. Now
> assuming pselect(), there are two states in the program: (a) SIGCONT is
> masked and we're outside of pselect(), that is, actively running, not
> blocking on anything; and (b) SIGCONT is unmasked and we're blocked on
> pselect(). On a conformant platform, the transition between these two is
> indivisible by delivery of a signal of interest. (This doesn't hold for
> the sigprocmask() + select() + sigprocmask() triplet, but let's ignore
> that :))
>
> 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). Since this state is purely CPU-bound, we'll
> reach the pselect() shortly. Upon entering pselect() (-> state (b)), it
> will be immediately interrupted by the signal handler, and the flag will
> be set. After return from pselect(), the mask will be atomically restored
> (ie. returning to state (a)).
>
> The return status of pselect() is checked in state (a). The flag is
> checked and reset in state (a) [*].
>
> In state (b) we're waiting for data, signals, and a timeout (... which
> could generally be the earliest of many deadlines, maintained in a
> priority queue). The process can be stopped in this state, and when
> continued, pselect() will immedietaly return (after the sighandler
> completes).
>
> [*] even if [p]select() doesn't return -1/EINTR -- on the Alpha OSF1 I had
> access to, if the process was stopped in select() for so long that the
> timeout would have passed, then at SIGCONT the process returned from
> select() with 0, even though the handler was run. This "robust" checking
> won't hurt where select() behaves correctly, and will catch this slight
> error.
>
> Sorry for this wall of text, I hope it's not incorrect. I'm positive I
> mixed up memories about multiple programs.

No problem. Thank you. My knowledge of signals is extremely limited.

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

#724

On 6/2/2011 8:54 PM, Joshua Maurice wrote:
> [...]
> No problem. Thank you. My knowledge of signals is extremely limited.

     That's probably a healthy state of affairs, as better-behaved
ways of dealing with asynchrony have come along.  Nurture and preserve
your ignorance of signals, just as you nurture and preserve your
ignorance of how to use leeches to cure infertility.  (Don't think
too hard about it; whatever your gender, you'll cringe.)

     I recall taking a kernel-internals course once, and in one of
the classes the teacher spent a long time taking us through all the
ins-and-outs of signal delivery -- they're startlingly complicated,
and dismayingly expensive.  He said, "When they finally bury Unix,
they'll chisel `It Was The Signals' on its gravestone."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#731

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
 
[...]

>     I recall taking a kernel-internals course once, and in one of
> the classes the teacher spent a long time taking us through all the
> ins-and-outs of signal delivery -- they're startlingly complicated,
> and dismayingly expensive.  He said, "When they finally bury Unix,
> they'll chisel `It Was The Signals' on its gravestone."

I'd wager a bet they will bury this guy first and the inscription will
read "He was polling as hard as he could, until he died from sheer
exhaustion, but unfortunately, he wouldn't ever let anyone interrupt
him" ...

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

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

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

csiph-web