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

#673 — threads, signals, and atomicity of basic types

Are basic types like int, long int, and long long int atomic when
accessed from different threads or from a signal handler, or must they
be protected using a pthread_mutex?

I think that those types will be atomic on most platforms if they can
be accessed in a single machine instruction and single bus cycle,
i.e. 32 bit ints on ia32, but not 64 bit ints on that platform.

In general, and if code should be portable, you cannot count on
atomicity and should use locks, right?

Next, if concurrent access is from different threads you can use
pthread_mutex_t to protect the access, but how can I protect access
from a signal handler?  AFAIK, if the signal handler can run in the
context of a thread holding the lock, it cannot take the lock, too.
Otherwise, you get undefined behavior.  Are there other mechanisms in
POSIX and/or ISO C?

Yet another question:  Do I need to use volatile to prevent compiler
optimization even if I protect data with a pthread_mutex?

urs

[toc] | [next] | [standalone]

#674

Le 31/05/2011 21:07, Urs Thuermann a écrit :
> Are basic types like int, long int, and long long int atomic when
> accessed from different threads or from a signal handler, or must they
> be protected using a pthread_mutex?

AFAIK, you need the mutex to flush the caches (r/w barriers), the
atomicity issue is not the (real) problem.

> Next, if concurrent access is from different threads you can use
> pthread_mutex_t to protect the access, but how can I protect access
> from a signal handler?  AFAIK, if the signal handler can run in the
> context of a thread holding the lock, it cannot take the lock, too.
> Otherwise, you get undefined behavior.  Are there other mechanisms in
> POSIX and/or ISO C?

Do not think so :( pthread_*() are unsafe in signal handlers.

> Yet another question:  Do I need to use volatile to prevent compiler
> optimization even if I protect data with a pthread_mutex?

Err, for what use ?

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

#678

Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
> Le 31/05/2011 21:07, Urs Thuermann a écrit :
>> Are basic types like int, long int, and long long int atomic when
>> accessed from different threads or from a signal handler, or must they
>> be protected using a pthread_mutex?
>
> AFAIK, you need the mutex to flush the caches (r/w barriers),

'Barriers' enforce a temporal ordering of memory accesses. They don't
'flush caches'. 

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

#680

Le 01/06/2011 12:58, Rainer Weikusat a écrit :
>> AFAIK, you need the mutex to flush the caches (r/w barriers),
> 'Barriers' enforce a temporal ordering of memory accesses. They don't
> 'flush caches'. 

Oops, yes, mixed caching issue and ordering.

Anyway, as said before, multithreading/synchronization and signals do
not mix very well..

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

#704

Le 01/06/2011 14:15, Xavier Roche a écrit :
> Le 01/06/2011 12:58, Rainer Weikusat a écrit :
>>> AFAIK, you need the mutex to flush the caches (r/w barriers),
>> 'Barriers' enforce a temporal ordering of memory accesses. They don't
>> 'flush caches'. 

Humm, correct me if I am wrong, but a memory barrier would also flush
the cache store/load buffer on some CPUs (at least it asks the CPU to
wait for the flush to be completed) as far as I understood ; this is not
just a temporal ordering on the compiler's side.

(See: "Memory Barriers: a Hardware View for Software Hackers",
<http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2009.04.05a.pdf>)

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

#707

Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes:
> Le 01/06/2011 14:15, Xavier Roche a écrit :
>> Le 01/06/2011 12:58, Rainer Weikusat a écrit :
>>>> AFAIK, you need the mutex to flush the caches (r/w barriers),
>>> 'Barriers' enforce a temporal ordering of memory accesses. They don't
>>> 'flush caches'. 
>
> Humm, correct me if I am wrong, but a memory barrier would also flush
> the cache store/load buffer on some CPUs (at least it asks the CPU to
> wait for the flush to be completed) as far as I understood ; this is not
> just a temporal ordering on the compiler's side.

'Cache' and 'store buffer' are two different things and it still only
imposes an ordering constraint:

	The memory barrier smp_mb() will cause the CPU
	to flush its store buffer before applying subsequent
	stores to their cache lines.
        [p. 9]

This doesn't say 'will cause ... hic et nunc' but 'will cause ...
before ...'.

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

#675

Urs Thuermann <urs@isnogud.escape.de> writes:
> Are basic types like int, long int, and long long int atomic when
> accessed from different threads or from a signal handler, or must they
> be protected using a pthread_mutex?

I don't know of any guarantee that the usual memory synchronization
rules cease to apply just because a signal handler is involved.

> I think that those types will be atomic on most platforms if they can
> be accessed in a single machine instruction and single bus cycle,
> i.e. 32 bit ints on ia32, but not 64 bit ints on that platform.

Once threads are involved the issue is not just atomicity but memory
synchronization between CPUs.

> In general, and if code should be portable, you cannot count on
> atomicity and should use locks, right?
>
> Next, if concurrent access is from different threads you can use
> pthread_mutex_t to protect the access, but how can I protect access
> from a signal handler?  AFAIK, if the signal handler can run in the
> context of a thread holding the lock, it cannot take the lock, too.

It cannot take the lock anyway - the locking functions are not
async-signal-safe.

You could try using sigwait() or similar instead.

> Yet another question:  Do I need to use volatile to prevent compiler
> optimization even if I protect data with a pthread_mutex?

No.

-- 
http://www.greenend.org.uk/rjk/

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

#677

On 5/31/2011 3:07 PM, Urs Thuermann wrote:
> Are basic types like int, long int, and long long int atomic when
> accessed from different threads or from a signal handler, or must they
> be protected using a pthread_mutex?

     Some may be atomic, others not.  Some may be atomic if
suitably aligned, non-atomic if misaligned.  It's up to the
individual implementation.

     But atomicity is usually not enough.  Even if Thread T1 can
store a new value in variable `foobar' and do so atomically, you
also need some idea of when (or even whether!) Thread T2 will
observe the new value.  Atomicity says that T2 will see either
the old value or the new value and not some kind of intermediate
amalgam, but says nothing about how many times T2 will see the
old before noticing the new.

     Finally, note that read-modify-write is almost never atomic
unless special machine instructions are used.  In particular,
`foobar++' and `foobar >>= 1' and `foobar |= 0x80' are almost
certainly non-atomic.

> I think that those types will be atomic on most platforms if they can
> be accessed in a single machine instruction and single bus cycle,
> i.e. 32 bit ints on ia32, but not 64 bit ints on that platform.

     "Most platforms."  Well, sure, for suitable values of "most."

> In general, and if code should be portable, you cannot count on
> atomicity and should use locks, right?

     Use locks, or use special instructions like compare-and-swap
or store-interlocked; these will usually be packaged inside what
appear to be C functions.  The important thing is that they will
provide both the atomicity and the visibility you need for effective
use of the shared variable, using memory barriers or other machine-
specific what-have-you.

> Next, if concurrent access is from different threads you can use
> pthread_mutex_t to protect the access, but how can I protect access
> from a signal handler?  AFAIK, if the signal handler can run in the
> context of a thread holding the lock, it cannot take the lock, too.
> Otherwise, you get undefined behavior.  Are there other mechanisms in
> POSIX and/or ISO C?

     Semaphores are async-signal-safe, I believe.  Even so, you can't
use them as a "locking" protocol, lest the signal arrive while the
protected object is "locked."  That is, the shared state must be the
semaphore itself, not something the semaphore "protects."

> Yet another question:  Do I need to use volatile to prevent compiler
> optimization even if I protect data with a pthread_mutex?

     Volatile is neither necessary nor sufficient.  In particular,
it doesn't solve the staleness problem mentioned above.

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

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

#679

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

[...]

>> Yet another question:  Do I need to use volatile to prevent compiler
>> optimization even if I protect data with a pthread_mutex?
>
>     Volatile is neither necessary nor sufficient.  In particular,
> it doesn't solve the staleness problem mentioned above.

The purpose of declaring something as 'volatile' is to inform a
ANSI/ISO C compiler that read accesses to that something should be
regarded as producing 'required side effects', ie that a sequence of
read accesses to some object without an intervening write access must not
be collapsed to a single 'machine read access' and subsequent reuse of
the value determined in this way. Whether this is technically
necessary for $something running on $some_platform depends on that
platform.

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

#693

On 6/1/2011 7:35 AM, Rainer Weikusat wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>
> [...]
>
>>> Yet another question:  Do I need to use volatile to prevent compiler
>>> optimization even if I protect data with a pthread_mutex?
>>
>>      Volatile is neither necessary nor sufficient.  In particular,
>> it doesn't solve the staleness problem mentioned above.
>
> The purpose of declaring something as 'volatile' is to inform a
> ANSI/ISO C compiler that read accesses to that something should be

     s/read //, with corresponding amendments in what follows.

> regarded as producing 'required side effects', ie that a sequence of
> read accesses to some object without an intervening write access must not
> be collapsed to a single 'machine read access' and subsequent reuse of
> the value determined in this way. Whether this is technically
> necessary for $something running on $some_platform depends on that
> platform.

     True.  Also, the question of whether memory visibility and
coherency issues arise in the first place depends on the platform.
What's your point?

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

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

#700

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 6/1/2011 7:35 AM, Rainer Weikusat wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>
>> [...]
>>
>>>> Yet another question:  Do I need to use volatile to prevent compiler
>>>> optimization even if I protect data with a pthread_mutex?
>>>
>>>      Volatile is neither necessary nor sufficient.  In particular,
>>> it doesn't solve the staleness problem mentioned above.
>>
>> The purpose of declaring something as 'volatile' is to inform a
>> ANSI/ISO C compiler that read accesses to that something should be
>
>     s/read //, with corresponding amendments in what follows.

	Accessing a volatile object, modifying an object, modifying a
	file, or calling a function that does any of those operations
	are all side effects
	[ISO/IEC 9899:1999 (E), 5.1.2.2.3|2]

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

#705

On 6/2/2011 6:22 AM, Rainer Weikusat wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>> On 6/1/2011 7:35 AM, Rainer Weikusat wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   writes:
>>>
>>> [...]
>>>
>>>>> Yet another question:  Do I need to use volatile to prevent compiler
>>>>> optimization even if I protect data with a pthread_mutex?
>>>>
>>>>       Volatile is neither necessary nor sufficient.  In particular,
>>>> it doesn't solve the staleness problem mentioned above.
>>>
>>> The purpose of declaring something as 'volatile' is to inform a
>>> ANSI/ISO C compiler that read accesses to that something should be
>>
>>      s/read //, with corresponding amendments in what follows.
>
> 	Accessing a volatile object, modifying an object, modifying a
> 	file, or calling a function that does any of those operations
> 	are all side effects
> 	[ISO/IEC 9899:1999 (E), 5.1.2.2.3|2]

     Exactly: So the effect of `volatile' is not restricted to
read accesses only, but also applies to write accesses.  And to
other accesses as well, since "what constitutes an access to an
object that has volatile-qualified type is implementation-defined"
(6.7.3p6), so the implementation is free to define additional and
exotic kinds of "access."

     But none of this has any bearing on the O.P.'s question, which
concerns the sharing of data objects between multiple threads of
execution.  C has no support for multiple threads (there's work in
progress for the next version of the Standard, but that version has
not yet been adopted or even finalized), and in particular C as it
stands lacks a memory model capable of speaking about how threads
can share data.  Using the `volatile' qualifier does not magically
call such a memory model into existence, and certainly doesn't say
anything about what can and can't be found in that absent model.

     If you're going to do multi-threading in C as it stands today,
you need to rely on guarantees that arise outside the language,
guarantees that come from other sources, like Pthreads.  The
Pthreads memory and synchronization model and mechanisms do not
rely on `volatile' as part of their API (`volatile' may or may
not have a role in the implementation of the interfaces, but that's
a side-issue, just as `#pragma POSIX_MAGIC=42' is).  Under Pthreads,
marking an object `volatile' does not make it shareable, and
omitting `volatile' does not make it un-shareable: Hence "neither
necessary nor sufficient," as mentioned by a couple people already.

     Pthreads is not the only multi-threading framework in existence,
of course, although it's certainly the one of greatest importance to
comp.unix.programmer.  It's possible that Frobozz Magic C has its
own multi-threading system, with an API in which `volatile' plays an
important part.  But that's Frobozz Magic C, not C and not Unix.

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

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

#706

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 6/2/2011 6:22 AM, Rainer Weikusat wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>> On 6/1/2011 7:35 AM, Rainer Weikusat wrote:
>>>> Eric Sosman<esosman@ieee-dot-org.invalid>   writes:
>>>>
>>>> [...]
>>>>
>>>>>> Yet another question:  Do I need to use volatile to prevent compiler
>>>>>> optimization even if I protect data with a pthread_mutex?
>>>>>
>>>>>       Volatile is neither necessary nor sufficient.  In particular,
>>>>> it doesn't solve the staleness problem mentioned above.
>>>>
>>>> The purpose of declaring something as 'volatile' is to inform a
>>>> ANSI/ISO C compiler that read accesses to that something should be
>>>
>>>      s/read //, with corresponding amendments in what follows.
>>
>> 	Accessing a volatile object, modifying an object, modifying a
>> 	file, or calling a function that does any of those operations
>> 	are all side effects
>> 	[ISO/IEC 9899:1999 (E), 5.1.2.2.3|2]
>
>     Exactly: So the effect of `volatile' is not restricted to
> read accesses only, but also applies to write accesses.

'Modifying an object' is always a side affect while merely 'accessing'
is only one of the object is volatile. That's quite clearly stated in
the (partial) sentence I quoted. Obviously, when 'modifying an object'
is a side effect and the set of volatile objects is a proper subset of
the set of objects, then 'modifying a volatile object' is also a side
effect, independentl of the qualifier.

[...]

>     But none of this has any bearing on the O.P.'s question, which
> concerns the sharing of data objects between multiple threads of
> execution.  C has no support for multiple threads (there's work in
> progress for the next version of the Standard, but that version has
> not yet been adopted or even finalized), and in particular C as it
> stands lacks a memory model capable of speaking about how threads
> can share data.  Using the `volatile' qualifier does not magically
> call such a memory model into existence, and certainly doesn't say
> anything about what can and can't be found in that absent model.

Well, why on earth would it? I'm actually quite amazed that somebody
could come up with this ludicrous idea and amazed - although to a
lesser degree - that these somebodies than shifted there erroneous
opinion on this topic from 'it is one' to 'well, it was sure meant to
be one, but it is broken' (people don't usually let go of an opinion
just because it is demonstrably wrong).

>     If you're going to do multi-threading in C as it stands today,
> you need to rely on guarantees that arise outside the language,
> guarantees that come from other sources, like Pthreads.  The
> Pthreads memory and synchronization model and mechanisms do not
> rely on `volatile' as part of their API

Again, why on earth would they? Concidentally, they also don't rely on
the 'right to keep and bear arms' or on the number of sheep in
Anartica and any number of other unrelated things.

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

#723

On 6/2/2011 8:38 AM, Rainer Weikusat wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>> On 6/2/2011 6:22 AM, Rainer Weikusat wrote:
>>> Eric Sosman<esosman@ieee-dot-org.invalid>   writes:
>>>> On 6/1/2011 7:35 AM, Rainer Weikusat wrote:
>>>>> Eric Sosman<esosman@ieee-dot-org.invalid>    writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Yet another question:  Do I need to use volatile to prevent compiler
>>>>>>> optimization even if I protect data with a pthread_mutex?
>>>>>>
>>>>>>        Volatile is neither necessary nor sufficient.  In particular,
>>>>>> it doesn't solve the staleness problem mentioned above.
>>>>>
>>>>> The purpose of declaring something as 'volatile' is to inform a
>>>>> ANSI/ISO C compiler that read accesses to that something should be
>>>>
>>>>       s/read //, with corresponding amendments in what follows.
>>>
>>> 	Accessing a volatile object, modifying an object, modifying a
>>> 	file, or calling a function that does any of those operations
>>> 	are all side effects
>>> 	[ISO/IEC 9899:1999 (E), 5.1.2.2.3|2]
>>
>>      Exactly: So the effect of `volatile' is not restricted to
>> read accesses only, but also applies to write accesses.
>
> 'Modifying an object' is always a side affect while merely 'accessing'
> is only one of the object is volatile. That's quite clearly stated in
> the (partial) sentence I quoted. Obviously, when 'modifying an object'
> is a side effect and the set of volatile objects is a proper subset of
> the set of objects, then 'modifying a volatile object' is also a side
> effect, independentl of the qualifier.

     Do you mean to say that `volatile' has no effect on write
accesses?  If so, please ponder

	/* volatile */ unsigned int *ioreg = ...;
	*ioreg = 42;
	*ioreg = 0x42;

With `volatile', both side-effects must actually be produced;
without it, the first can be discarded under the "as if" rule.

>>      But none of this has any bearing on the O.P.'s question, which
>> concerns the sharing of data objects between multiple threads of
>> execution.  C has no support for multiple threads (there's work in
>> progress for the next version of the Standard, but that version has
>> not yet been adopted or even finalized), and in particular C as it
>> stands lacks a memory model capable of speaking about how threads
>> can share data.  Using the `volatile' qualifier does not magically
>> call such a memory model into existence, and certainly doesn't say
>> anything about what can and can't be found in that absent model.
>
> Well, why on earth would it?

     Um, er, because that's what you've been implying by insisting
that `volatile' is somehow relevant the question at hand?  No, that's
too obvious, Holmes will surely come up with some startling inference
beyond my poor powers to grasp, I tremble with anticipation of the
revelation of his brilliance.

>>      If you're going to do multi-threading in C as it stands today,
>> you need to rely on guarantees that arise outside the language,
>> guarantees that come from other sources, like Pthreads.  The
>> Pthreads memory and synchronization model and mechanisms do not
>> rely on `volatile' as part of their API
>
> Again, why on earth would they?

     As I said, they don't.  And that's why `volatile' is neither
necessary nor sufficient for sharing data between threads.  (You do
remember, I hope, that this thread is about, er, threads?  Or have
you lost sight of -- or feigned to lose sight of -- that fact?)

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

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

#683

On May 31, 12:07 pm, Urs Thuermann <u...@isnogud.escape.de> wrote:

> Are basic types like int, long int, and long long int atomic when
> accessed from different threads or from a signal handler, or must they
> be protected using a pthread_mutex?

They may or may not be on particular platforms. If the platform
provides specific atomic operations, you can use them to guarantee
atomicity. If not, nothing guarantees atomicity.

> I think that those types will be atomic on most platforms if they can
> be accessed in a single machine instruction and single bus cycle,
> i.e. 32 bit ints on ia32, but not 64 bit ints on that platform.

In general, reads will be atomic and writes will be atomic in the
sense that you won't see word tearing on properly-aligned values. But
increments and other read-modify-write operations will generally not
be atomic automatically even if the platform has the capability to
provide such.

> In general, and if code should be portable, you cannot count on
> atomicity and should use locks, right?

You should use locks and then you are welcome to provide platform-
specific optimizations on those platforms that do provide atomic
operations.

> Next, if concurrent access is from different threads you can use
> pthread_mutex_t to protect the access, but how can I protect access
> from a signal handler?  AFAIK, if the signal handler can run in the
> context of a thread holding the lock, it cannot take the lock, too.
> Otherwise, you get undefined behavior.  Are there other mechanisms in
> POSIX and/or ISO C?

You should redesign so you don't need to do this. In general, avoid
having threads interrupted by signals in any but error paths. (Or
where a signal is used just to force a system call to return.)

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

DS

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

#684

David Schwartz <davids@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. '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. 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.

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

#714

On 01/06/2011 22:54, Rainer Weikusat wrote:
> David Schwartz<davids@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. '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. In practice, it is usually not necessary.

Is this because the compiler "usually" can't easily work out whether 
those unrelated subroutines may have the side-effect of modifying the 
value, so it doesn't try, therefore must assume modification is 
possible, and therefore must load the value exactly as it would if the 
object was declared volatile?

Alex

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

#739

On Jun 2, 1:00 pm, Alex Fraser <m...@privacy.net> wrote:

> Is this because the compiler "usually" can't easily work out whether
> those unrelated subroutines may have the side-effect of modifying the
> value, so it doesn't try, therefore must assume modification is
> possible, and therefore must load the value exactly as it would if the
> object was declared volatile?

It's false, so it's not "because" of anything. In reality, the compile
officially supports whatever threading model you are using, or you
wouldn't be using it. If that means the compiler cannot do certain
optimizations that it might otherwise do, so be it.

DS

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

#741

David Schwartz <davids@webmaster.com> writes:
> On Jun 2, 1:00 pm, Alex Fraser <m...@privacy.net> wrote:
>
>> Is this because the compiler "usually" can't easily work out whether
>> those unrelated subroutines may have the side-effect of modifying the
>> value, so it doesn't try, therefore must assume modification is
>> possible, and therefore must load the value exactly as it would if the
>> object was declared volatile?
>
> It's false, so it's not "because" of anything.

It's not. Declaring that an object is 'volatile' is supposed to
inform an ANSI/ISO C compiler that 'accessing the object' (as opposed
to 'modifiying the object') should be regarded as a side effect , IOW,
that the 'access procedure' is not idempotent, despite this cannot be
concluded by inspecting the code which is executed between two such
accesses itself. 

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

#748

On Jun 5, 8:39 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> It's not. Declaring that an object is 'volatile' is supposed to
> inform an ANSI/ISO C compiler that 'accessing the object' (as opposed
> to 'modifiying the object') should be regarded as a side effect

Nobody has ever explained what this means.

> , IOW,
> that the 'access procedure' is not idempotent, despite this cannot be
> concluded by inspecting the code which is executed between two such
> accesses itself.

Nobody has ever explained what this means either. It's supposed to
mean that the access is visible somewhere, but nobody knows what that
somewhere is.

The ANSI/ISO standard is platform-independent. But what constitutes an
"access" and where one might be required to be visible cannot possibly
be described in a platform-independent way. This is why no threading
standard in existence makes use of this property of 'volatile'.

DS

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

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

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

csiph-web