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

#749

On Mon, 06 Jun 2011 18:48:19 -0700, David Schwartz 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.

It can't actually be explained, for the reason you suggest:

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

The only cases where the standard really says anything specific about
"volatile" are with regard to setjmp/longjmp and signals. The rest boils
down to the compiler doing the "sane" thing. In much the same way that the
standard doesn't actually specify what it means to "read" or "write" a
"file"; it just assumes that these concepts are meaningful.

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

#755

On Jun 6, 10:50 pm, Nobody <nob...@nowhere.com> wrote:

> The only cases where the standard really says anything specific about
> "volatile" are with regard to setjmp/longjmp and signals. The rest boils
> down to the compiler doing the "sane" thing. In much the same way that the
> standard doesn't actually specify what it means to "read" or "write" a
> "file"; it just assumes that these concepts are meaningful.

Unfortunately, the compiler doing the sane thing doesn't help you one
bit. Any optimization the compiler can make can, at least in theory,
be made by other components of the system. Because the standard
doesn't specify where accesses are observed, it's not clear what
that's supposed to mean. For example, should 'volatile' bypass cache
and force access to/from memory directly? It doesn't on any platform I
know of. But arguably cache optimizes away 'volatile' accesses,
modifying the observable behavior of the system. The compiler could
bypass the cache for these accesses.

DS

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

#763

On Tue, 07 Jun 2011 06:04:20 -0700, David Schwartz wrote:

>> The only cases where the standard really says anything specific about
>> "volatile" are with regard to setjmp/longjmp and signals. The rest boils
>> down to the compiler doing the "sane" thing. In much the same way that the
>> standard doesn't actually specify what it means to "read" or "write" a
>> "file"; it just assumes that these concepts are meaningful.
> 
> Unfortunately, the compiler doing the sane thing doesn't help you one
> bit. Any optimization the compiler can make can, at least in theory,
> be made by other components of the system. Because the standard
> doesn't specify where accesses are observed, it's not clear what
> that's supposed to mean. For example, should 'volatile' bypass cache
> and force access to/from memory directly? It doesn't on any platform I
> know of. But arguably cache optimizes away 'volatile' accesses,
> modifying the observable behavior of the system. The compiler could
> bypass the cache for these accesses.

"Sane" is a judgment call, not something which can formally be specified.

In practice, it usually means that the compiler will emit load/store
instructions which correspond directly to the source code (i.e. if you
read an lvalue within a loop, the compiler won't move the load instruction
outside the loop).

It usually doesn't involve emitting specialised instructions (e.g. memory
barriers), accessing specialised registers, manipulating hardware (e.g.
the MMU), etc.

"volatile" was added to ANSI C to deal with the specific case that many
generally-useful optimisations can be problematic in a very few, very
specialised cases (e.g. accessing memory-mapped hardware).

I've always interpreted it as "don't optimise this", something which
should only be necessary if optimisations are enabled in the first place.
As such, I wouldn't expect its presence to cause the compiler to emit
anything which it would never emit in its absence.

IOW, it stops the compiler performing its own optimisations. It doesn't
cause the compiler to add workarounds for the hardware's optimisations.

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

#765

Nobody <nobody@nowhere.com> writes:
> On Tue, 07 Jun 2011 06:04:20 -0700, David Schwartz wrote:

[...]

> "volatile" was added to ANSI C to deal with the specific case that many
> generally-useful optimisations can be problematic in a very few, very
> specialised cases (e.g. accessing memory-mapped hardware).
>
> I've always interpreted it as "don't optimise this", something which
> should only be necessary if optimisations are enabled in the first place.
> As such, I wouldn't expect its presence to cause the compiler to emit
> anything which it would never emit in its absence.
>
> IOW, it stops the compiler performing its own optimisations. It doesn't
> cause the compiler to add workarounds for the hardware's optimisations.

IMO, expecting the latter doesn't make any sense. C implementations
are generally free to produce 'equivalent code', meaning, code which
isn't a literal translation of a sequence of C expressions into the
corresponding machine code sequences but into some other machine code
sequences which happen to produce the same result, cf

	An actual implementation need not evaluate part of an
	expression if it can deduce that its value is not used and
	that no needed side effects are produced

In the addition example I gave (*b + *b + *b + *b) the values which
could be obtained by evualuating the three trailing *b expressions are
not used and neither do they produce any side effects. Possibly, even
the value of the first *b is never used, eg, when a statement a la

	*b = c;

preceded it. And a volatile qualifier is supposed to inform a C
implementation that these relaxed expression evaluation rules should
be suspended in some particular context. All of this happens purely at
the C language level.

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

#766

>> "volatile" was added to ANSI C to deal with the specific case that many
>> generally-useful optimisations can be problematic in a very few, very
>> specialised cases (e.g. accessing memory-mapped hardware).
>>
>> I've always interpreted it as "don't optimise this", something which
>> should only be necessary if optimisations are enabled in the first place.
>> As such, I wouldn't expect its presence to cause the compiler to emit
>> anything which it would never emit in its absence.

One of the problems with this is that there is no definition of
"unoptimized".  In particular, given any piece of code, it is always
possible to make it *WORSE* (say, by adding branches-to-branches),
adding delay loops, or doing additions one bit at a time.

Given the code:
	z += 100;

is it an optimization to generate code faster than:
	z += atoi("100");
or
	z += 100*atoi("1")+10*atoi("0")+1*atoi("0");
?

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

#768

gordonb.lhpq6@burditt.org (Gordon Burditt) writes:
>>> "volatile" was added to ANSI C to deal with the specific case that many
>>> generally-useful optimisations can be problematic in a very few, very
>>> specialised cases (e.g. accessing memory-mapped hardware).
>>>
>>> I've always interpreted it as "don't optimise this", something which
>>> should only be necessary if optimisations are enabled in the first place.
>>> As such, I wouldn't expect its presence to cause the compiler to emit
>>> anything which it would never emit in its absence.
>
> One of the problems with this is that there is no definition of
> "unoptimized".

That's a problem with the term 'optimization' when used in this
context. Given that 'optimizing compilers' rarely - if ever - produce
'optimal code' and if so, only by accident, and that this
'optimization' consequently isn't an 'optimization' at all, neither
when considering the literal meaning of the word nor its common
mathematic definition, the best course of action in this respect would
be to avoid using it at all: When applied to 'code transformators',
its usage is entirely political -- the 'compiler consumer' is supposed
to suspend his own critical thinking in favour of blindly believing
that whatever code transformation someone happens to have coded into a
compiler will always be beneficial, actually, even 'optimal', in any
given situation because - see - it's called 'optimization', while the
reality is, of course, that the majority of 'compiler optimizations'
are exactly as useful as unconditional micro-optimization of code
always happens to be -- at best, they neither hurt nor help and more
often than not, they actually do hurt.

Regarding 'volatile', things become much clearer when restricting
oneself to the terminology the C-standard uses for this: A C-program
is composed of a sequence of expressions which are evaluated according
to their defined semantics. Provided it can be proven that not
evaluating a specific expression won't change the result of the
program, the evaluation may be omitted. In this particular case, the
expressions in questions are those who 'access' objects, meaning,
determine their present value without modifying it. Assuming that b is
a pointer to some object, *b is an expression accessing this
object. Evaluating it corresponds to executing whatever code happens
to be necessary to 'determine' what happens to be stored at the memory
locations b points to. In absence of volatile, this may be omitted if
the compiler already knows the value which will reside there at
execution time. Otherwise, the code necessary for evaluating *b is
supposed to be generated unconditionally.

How 'the memory system' itself deals with this code is something which
happens at a lower level of abstraction than the one provided by the C
language and insofar what the memory system will do is not what
happens to be necessary, something machine-specific might need to be
done in order to counter that *if possible*. Eg, at least for the ARM9
MMU (the only one I've ever written code for myself), cachability of
accesses to specific virtual memory locations is controlled by
attributes in the corresponding parts of the page table(s). When
accessing memory-mapped device registers, the corresponding virtual
addresses obviously need to be marked as 'uncacheable' for the 'access
code' generated by the C compiler to actually hit those registers, but
the compiler itself still needs to be instructed to actually generate
this code.

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

#772

On Jun 8, 3:09 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> That's a problem with the term 'optimization' when used in this
> context. Given that 'optimizing compilers' rarely - if ever - produce
> 'optimal code' and if so, only by accident, and that this
> 'optimization' consequently isn't an 'optimization' at all, neither
> when considering the literal meaning of the word nor its common
> mathematic definition, the best course of action in this respect would
> be to avoid using it at all: When applied to 'code transformators',
> its usage is entirely political -- the 'compiler consumer' is supposed
> to suspend his own critical thinking in favour of blindly believing
> that whatever code transformation someone happens to have coded into a
> compiler will always be beneficial, actually, even 'optimal', in any
> given situation because - see - it's called 'optimization', while the
> reality is, of course, that the majority of 'compiler optimizations'
> are exactly as useful as unconditional micro-optimization of code
> always happens to be -- at best, they neither hurt nor help and more
> often than not, they actually do hurt.

You claim that, on average, a program compiled with gcc will run about
as fast, and with about as much memory footprint, under -O0 and -O3?
You're insane.

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

#775

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

> That's a problem with the term 'optimization' when used in this
> context. Given that 'optimizing compilers' rarely - if ever - produce
> 'optimal code' and if so, only by accident, and that this
> 'optimization' consequently isn't an 'optimization' at all, neither
> when considering the literal meaning of the word nor its common
> mathematic definition, the best course of action in this respect would
> be to avoid using it at all: When applied to 'code transformators',
> its usage is entirely political -- the 'compiler consumer' is supposed
> to suspend his own critical thinking in favour of blindly believing
> that whatever code transformation someone happens to have coded into a
> compiler will always be beneficial, actually, even 'optimal', in any
> given situation because - see - it's called 'optimization', while the
> reality is, of course, that the majority of 'compiler optimizations'
> are exactly as useful as unconditional micro-optimization of code
> always happens to be -- at best, they neither hurt nor help and more
> often than not, they actually do hurt.

You are obviously not as idiotic as the content behind this because if
you were, you wouldn't be able to form complete sentences. So you are
something of a paradox. On the bright side, if you were correct, CPUs
wouldn't need any registers. Operating on registers, rather than
memory, is a compiler optimization.

DS

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

#777

David Schwartz <davids@webmaster.com> writes:
> On Jun 8, 3:09 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> That's a problem with the term 'optimization' when used in this
>> context. Given that 'optimizing compilers' rarely - if ever - produce
>> 'optimal code' and if so, only by accident, and that this
>> 'optimization' consequently isn't an 'optimization' at all, neither
>> when considering the literal meaning of the word nor its common
>> mathematic definition, the best course of action in this respect would
>> be to avoid using it at all: When applied to 'code transformators',
>> its usage is entirely political -- the 'compiler consumer' is supposed
>> to suspend his own critical thinking in favour of blindly believing
>> that whatever code transformation someone happens to have coded into a
>> compiler will always be beneficial, actually, even 'optimal', in any
>> given situation because - see - it's called 'optimization', while the
>> reality is, of course, that the majority of 'compiler optimizations'
>> are exactly as useful as unconditional micro-optimization of code
>> always happens to be -- at best, they neither hurt nor help and more
>> often than not, they actually do hurt.
>
> You are obviously not as idiotic as the content behind this because if
> you were, you wouldn't be able to form complete sentences.

The reason for this is that I'm right despite this happens to
contradict all kinds of 'established opinions'. But please feel free
to point out any why I'm wrong, instead of just asserting that I
certainly must be. Eg, is it wrong that - mathematically -
'optimization' refers to 'finding the best [optimal] solution' but
that so-called 'compiler optimization' doesn't yield 'optimal
solutions'?

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

#779

On Fri, 10 Jun 2011 15:26:13 +0100, Rainer Weikusat wrote:
> David Schwartz <davids@webmaster.com> writes:
>> On Jun 8, 3:09 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>> That's a problem with the term 'optimization' when used in this
>>> context. Given that 'optimizing compilers' rarely - if ever - produce
>>> 'optimal code' and if so, only by accident, and that this
>>> 'optimization' consequently isn't an 'optimization' at all, neither
>>> when considering the literal meaning of the word nor its common
>>> mathematic definition, the best course of action in this respect would
>>> be to avoid using it at all: When applied to 'code transformators',
>>> its usage is entirely political -- the 'compiler consumer' is supposed
>>> to suspend his own critical thinking in favour of blindly believing
>>> that whatever code transformation someone happens to have coded into a
>>> compiler will always be beneficial, actually, even 'optimal', in any
>>> given situation because - see - it's called 'optimization', while the
>>> reality is, of course, that the majority of 'compiler optimizations'
>>> are exactly as useful as unconditional micro-optimization of code
>>> always happens to be -- at best, they neither hurt nor help and more
>>> often than not, they actually do hurt.
>>
>> You are obviously not as idiotic as the content behind this because if
>> you were, you wouldn't be able to form complete sentences.
> 
> The reason for this is that I'm right despite this happens to contradict
> all kinds of 'established opinions'. But please feel free to point out
> any why I'm wrong, instead of just asserting that I certainly must be.
> Eg, is it wrong that - mathematically - 'optimization' refers to
> 'finding the best [optimal] solution' but that so-called 'compiler
> optimization' doesn't yield 'optimal solutions'?

Before I comment on the latter question [re optimization definition],
let me hasten to say how bad it was of David Schwartz to introduce 
even a hint of ad hominem remarks.  I for one certainly don't agree 
with his comment that you obviously are not as idiotic as your writing
makes you look.  In any case there is no need for anyone to make such
remarks, as your writing is already out there for us all to see.

Now, regarding the definition of optimization, it is true that
in a mathematical context optimization refers to finding optimal
solutions.  But more generally, it refers to the process of 
trying to find good solutions.  For example, Merriam-Webster
defines optimization as "an act, process, or methodology of 
making something (as a design, system, or decision) as fully 
perfect, functional, or effective as possible".  That definition
is so broad that it easily encompasses ordinary program optimization
mechanisms, which usually are processes or methods that do as much
as they can do to improve program performance or decrease program
cost, given limited resources and competing objectives.  

Whether true or not, your previous assertion that "the majority 
of 'compiler optimizations' are exactly as useful as unconditional
micro-optimization of code always happens to be..." does not support
your nonsensical claims that optimization is "entirely political" and
consumers are "supposed to suspend ... critical thinking in favour
of blindly believing".  Given the vast number of transformations
that are possible, one cannot rationally expect a majority of them
to be useful or applicable to a given program.  What is more 
relevant is the fairly clear fact that many large or long running 
programs are smaller and/or faster when compiled with gcc -O3
vs compiled with no optimization.

The discussion in this subthread has wandered away from threads, 
signals, and atomicity of basic types, but of course you could start
a new thread, with your "I'm right despite this happens to contradict 
all kinds of 'established opinions'" claim as the subject line.  If 
you craft the initial post carefully enough, you probably could arrange
that only you could be right, and everyone else necessarily wrong.  :(

-- 
jiw

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

#780

James Waldby <not@valid.invalid> writes:
> On Fri, 10 Jun 2011 15:26:13 +0100, Rainer Weikusat wrote:
>> David Schwartz <davids@webmaster.com> writes:
>>> On Jun 8, 3:09 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>>> That's a problem with the term 'optimization' when used in this
>>>> context. Given that 'optimizing compilers' rarely - if ever - produce
>>>> 'optimal code' and if so, only by accident, and that this
>>>> 'optimization' consequently isn't an 'optimization' at all, neither
>>>> when considering the literal meaning of the word nor its common
>>>> mathematic definition, the best course of action in this respect would
>>>> be to avoid using it at all: When applied to 'code transformators',
>>>> its usage is entirely political -- the 'compiler consumer' is supposed
>>>> to suspend his own critical thinking in favour of blindly believing
>>>> that whatever code transformation someone happens to have coded into a
>>>> compiler will always be beneficial, actually, even 'optimal', in any
>>>> given situation because - see - it's called 'optimization',

[...]

>>> You are obviously not as idiotic as the content behind this because if
>>> you were, you wouldn't be able to form complete sentences.
>> 
>> The reason for this is that I'm right despite this happens to contradict
>> all kinds of 'established opinions'. But please feel free to point out
>> any why I'm wrong,

[...]

> Now, regarding the definition of optimization, it is true that
> in a mathematical context optimization refers to finding optimal
> solutions.  But more generally, it refers to the process of 
> trying to find good solutions.  For example, Merriam-Webster
> defines optimization as "an act, process, or methodology of 
> making something (as a design, system, or decision) as fully 
> perfect, functional, or effective as possible".
> That definition is so broad that it easily encompasses ordinary
> program optimization mechanisms,

This definition is essentially a non-circular way to express that
'optimization is the process of finding an optimal solution' (somewhat
simplified in order to ease understanding).

> which usually are processes or methods that do as much
> as they can do to improve program performance or decrease program
> cost, given limited resources and competing objectives.

And this means exactly nothing: That someone does 'as much as he can'
to 'improve program performance' neither implies that program
performance actually improved because of it nor precludes that program
performance got worse. There is an important difference between 'the
process of finding an optimal solution' and 'the process of trying to
improve something': The former results in an optimal solution. The
latter results in $something, depending on the success of the attempt.

> Whether true or not, your previous assertion that "the majority 
> of 'compiler optimizations' are exactly as useful as unconditional
> micro-optimization of code always happens to be..." does not support
> your nonsensical claims that optimization is "entirely political" and
> consumers are "supposed to suspend ... critical thinking in favour
> of blindly believing".

Did you notice that you've turned my sentence upside down and inserted
a a premise - conclusion relation into it which it didn't orignally
contain? I agree that this construct makes no sense. But that's your
construct and you purposely constructed it such that it doesn't. What
I actually wrote about that was "Because compiler optimization does
not yield optimal solutions and isn't even intended to, using the
term 'optimization' for this process is essentially propaganda".

[...]

> The discussion in this subthread has wandered away from threads, 
> signals, and atomicity of basic types,

Not really, because the paragraph you (and David Schwartz) were
replying to was supposed to get the 'optimization' with its nebolous
technical meaning out of the way of describing the semantic of the
ISO-C volatile qualifier.

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

#781

On Jun 10, 9:49 am, James Waldby <n...@valid.invalid> wrote:
> On Fri, 10 Jun 2011 15:26:13 +0100, Rainer Weikusat wrote:
> > David Schwartz <dav...@webmaster.com> writes:
> >> You are obviously not as idiotic as the content behind this because if
> >> you were, you wouldn't be able to form complete sentences.
>
> > The reason for this is that I'm right despite this happens to contradict
> > all kinds of 'established opinions'. But please feel free to point out
> > any why I'm wrong, instead of just asserting that I certainly must be.
> > Eg, is it wrong that - mathematically - 'optimization' refers to
> > 'finding the best [optimal] solution' but that so-called 'compiler
> > optimization' doesn't yield 'optimal solutions'?
>
> Before I comment on the latter question [re optimization definition],
> let me hasten to say how bad it was of David Schwartz to introduce
> even a hint of ad hominem remarks.  I for one certainly don't agree
> with his comment that you obviously are not as idiotic as your writing
> makes you look.  In any case there is no need for anyone to make such
> remarks, as your writing is already out there for us all to see.

I've concluded that he's a troll, or obstinate enough that he's
functionally a troll. He's starting to remind me very much of Paul of
comp.lang.c++ infamy. Call that ad hominem if you want. Let me pose to
you this. What's worse, 1- making a snide remark, or 2- making a
fatuous absurd claim that most modern compiler optimizations on the
average hinder as much as they help, and making an argument resting on
a straw man pedantic definition of optimize?

Good luck in future discussion in what I'm sure will be a fruitless
conversation.

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

#751

David Schwartz <davids@webmaster.com> writes:
> 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.

I suggest that you get yourself a copy of the C standard and start
looking for operators whose semantics imply that they can be used to
'access objects' without modifiying them. After all, if the C standard
use the term 'accessing an object', it can only refer to some
operation which is part of the C language. This would be the
[]-operator and the *-operator when not being used as lvalues and
possibly, the &-operator. Also, what precisely constitutes an 'access
to an object with a volatile-qualified type' is implementation
defined behaviour. This means it is 'unspecified behaviour' (the C
standard 'provides two or more possibilities and imposes no further
requirements on which is chosen in any instance') and 'each
implementation documentes how the choice is made'.

Consequently, you statement above is roughly equivalent to "I haven't
ever bothered to consult the relevant documentation".

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

I suspect you are playing dumb on purpose, because you also simply
don't want to let go of the erroneous notation that 'volatile' is
somehow related to 'threading'. It isn't, although 'threading' is one
of the cases where volatile is theoretically necessary (because the
existence of multiple threads implies that 'object accesses' are not
necessarily idempotent, similar to the way they are already not
necessarily idempotent because of effects of signal handlers).

The 'visibility' you mention above is an attribute of some particular
'memory model' and since the C standard does not define a memory
model, it can talk about attributes of memory models, either.

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

#754

On Jun 7, 4:55 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:

> I suspect you are playing dumb on purpose, because you also simply
> don't want to let go of the erroneous notation that 'volatile' is
> somehow related to 'threading'. It isn't, although 'threading' is one
> of the cases where volatile is theoretically necessary (because the
> existence of multiple threads implies that 'object accesses' are not
> necessarily idempotent, similar to the way they are already not
> necessarily idempotent because of effects of signal handlers).

This is a completely absurd argument and does a serious dis-service to
anyone who reads it. *Every* significant threading standard provides a
mechanism that is explicitly guaranteed to be sufficient. If the
standard says X is sufficient, and X is not 'volatile', then
'volatile' is not necessary. The WIN32 threading standard does this.
The POSIX threading standard does this. The old Solaris threading
standard does this. And so on. On none of these platforms is
'volatile' necessary because the relevant standards provide methods
that actually work.

Your argument is that 'volatile' is necessary but not sufficient. That
means something else would be needed. Any rational person designing a
standard would make whatever that additional thing is sufficient by
itself, because otherwise you'd need two mechanisms to do the most
simply thing you could ever want to do.

DS

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

#757

David Schwartz <davids@webmaster.com> writes:
> On Jun 7, 4:55 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
>> I suspect you are playing dumb on purpose, because you also simply
>> don't want to let go of the erroneous notation that 'volatile' is
>> somehow related to 'threading'. It isn't, although 'threading' is one
>> of the cases where volatile is theoretically necessary (because the
>> existence of multiple threads implies that 'object accesses' are not
>> necessarily idempotent, similar to the way they are already not
>> necessarily idempotent because of effects of signal handlers).
>
> This is a completely absurd argument and does a serious dis-service to
> anyone who reads it. *Every* significant threading standard provides

... all kinds of stuff. But since 'threading' is something outside of
the scope of the current C standard, that's besides the point insofar
things inside the scope of the C standard are concerned. 'volatile' is
a type qualifier whose purpose is to inform an ISO-compliant C
compiler that accesses to an object should be regarded as 'side
effects', IOW, that these accesses are not idempotent 'for some
reason' (which will often be outside the scope of the C-standard,
too). Eg, assuming the following declarations and code (and assuming
that b has been initialized to a valid pointer):

	unsigned a;
        volatile unsigned *b;

        a = *b + *b + *b + *b;

In absence of the volatile qualifier, this could, for instance, be
transformed into

	a = *b << 2;

but the volatile prohibits this. Similarly, assuming

	volatile sig_atomic_t wkscrft;

        while (!wkscrft);

the loop condition must not be replaced by the seemingly equivalent

	while (1)

and because of this, a signal handler can change the value of wkscrft
and the loop will terminate at some unspecified, later time. In a
POSIX environment, this signal handler could be executed by a
different thread than the one running the loop.

[...]

> Your argument is that 'volatile' is necessary but not sufficient. That
> means something else would be needed. Any rational person designing a
> standard would make whatever that additional thing is sufficient by
> itself, because otherwise you'd need two mechanisms to do the most
> simply thing you could ever want to do.

The reason why 'two mechanisms' are theoretically needed is because
one takes care of 'the C language side' (IOW, instructs 'the C
compiler' to generate code performing a specific set of actions
instead of generating code to perform some set of seemingly equivalent
other actions) while the other mechanism is part of the (completely
orthogonal) threading standard.

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

#759

On Jun 7, 8:05 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> David Schwartz <dav...@webmaster.com> writes:
> > Your argument is that 'volatile' is necessary but not sufficient. That
> > means something else would be needed. Any rational person designing a
> > standard would make whatever that additional thing is sufficient by
> > itself, because otherwise you'd need two mechanisms to do the most
> > simply thing you could ever want to do.
>
> The reason why 'two mechanisms' are theoretically needed is because
> one takes care of 'the C language side' (IOW, instructs 'the C
> compiler' to generate code performing a specific set of actions
> instead of generating code to perform some set of seemingly equivalent
> other actions) while the other mechanism is part of the (completely
> orthogonal) threading standard.

Except threading doesn't work that way. The compiler /must/ be
threading aware. It needs to know that it may not move code in certain
directions past certain kinds of primitives, like pthread_mutex_lock.
volatile does not do that. Generally it happens to be a single
primitive like pthread_mutex_lock which the compiler understands,
which is then transformed into the appropriate assembly so that the
hardware understands, but the first primitive must be a threading
primitive which the threading aware compiler understands.

You are welcome to continue repeating the C specification of volatile
that it's there to ensure that "The compiler does the right thing",
but you are wrong insofaras the common understanding, and more
importantly basically all compiler implementations (except maybe win32
compilers). Volatile is neither necessary nor sufficient for inter-
thread communication (except maybe win32).

Also, you continue to post that the rest of us think volatile is
related to threading (in other posts, not quoted here). I don't know
why you're doing that. No one has claimed that. In fact, the rest of
us have been very clear in that volatile is completely unrelated to
threading, and the stronger statement that if you're trying to use
volatile for inter-thread communication then your program has
undefined behavior according to pretty much every threading standard
for C that exists (besides maybe win32).

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

#800

Joshua Maurice <joshuamaurice@gmail.com> writes:
>On Jun 7, 8:05=A0am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> David Schwartz <dav...@webmaster.com> writes:
>> > Your argument is that 'volatile' is necessary but not sufficient. That
>> > means something else would be needed. Any rational person designing a
>> > standard would make whatever that additional thing is sufficient by
>> > itself, because otherwise you'd need two mechanisms to do the most
>> > simply thing you could ever want to do.
>>
>> The reason why 'two mechanisms' are theoretically needed is because
>> one takes care of 'the C language side' (IOW, instructs 'the C
>> compiler' to generate code performing a specific set of actions
>> instead of generating code to perform some set of seemingly equivalent
>> other actions) while the other mechanism is part of the (completely
>> orthogonal) threading standard.
>
>Except threading doesn't work that way. The compiler /must/ be
>threading aware. It needs to know that it may not move code in certain
>directions past certain kinds of primitives, like pthread_mutex_lock.

Actually, the compiler doesn't know for beans what a function
called 'pthread_mutex_lock' does, or requires.   The C standard
has certain rules about moving code about, and one of them is that
code cannot be moved around a sequence point.   A function call
is a sequence point, which works for both posix and wih32 thread
synchronization primitives.

Note that operating systems, written in C, are very multithreaded
programs that don't use posix or win32 user-level API's for synchronization
(but because the function calls are sequence points, the compiler is
forbiddden to move code across the sequence point in either
direction).

scott

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

#802

On Tue, 14 Jun 2011 21:43:44 +0000, Scott Lurndal wrote:

>>Except threading doesn't work that way. The compiler /must/ be
>>threading aware. It needs to know that it may not move code in certain
>>directions past certain kinds of primitives, like pthread_mutex_lock.
> 
> Actually, the compiler doesn't know for beans what a function
> called 'pthread_mutex_lock' does, or requires.   The C standard
> has certain rules about moving code about, and one of them is that
> code cannot be moved around a sequence point.

That's wrong. Optimising compilers move code around sequence points all
the time. They wouldn't be able to do much optimisation if they didn't.
Bear in mind that lots of things are sequence points beside function
calls, including:

         -- The   end   of  the  first  operand  of  the  following
            operators: logical  AND  &&  (6.5.13);  logical  OR  ||
            (6.5.14); conditional ? (6.5.15); comma , (6.5.17).

         -- The  end  of a full expression: an initializer (6.7.8);
            the expression in an expression statement (6.8.3);  the
            controlling  expression of a selection statement (if or
            switch) (6.8.4); the controlling expression of a  while
            or  do statement (6.8.5); each of the three expressions
            of a for  statement  (6.8.5.3);  the  expression  in  a
            return statement (6.8.6.4).

The main significance of sequence points in C is that modifying an lvalue
more than once between sequence points results in undefined behaviour
(e.g. "x = ++x;" is undefined because it modifies x twice without an
intervening sequence point).

The reason why compilers tend to avoid moving code around function calls
is that it's much harder to guarantee equivalence. When moving code around
other statements, the compiler can determine what data those statements
read and write, so it can determine whether there's any interaction with
the code being moved. But it can't normally determine the behaviour of an
external function.

But this doesn't apply to functions which are inlined, or which use
e.g. gcc's __attribute__((pure)). Nor does it apply if the code being
moved doesn't read or write memory which might affect or be affected by
the function (e.g. if the code only reads or writes local variables and
there is no "legitimate" means for the function to obtain a pointer to any
of those variables).

In the case of pthread_mutex_lock(), the compiler doesn't know what that
function does, so it has to assume that it may read and/or write any
global data or any data which could be referenced via its pthread_mutex_t*
argument. Consequently, it can't move any code which reads or writes such
data around the function call.

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

#805

Nobody <nobody@nowhere.com> writes:
> On Tue, 14 Jun 2011 21:43:44 +0000, Scott Lurndal wrote:
>
>>>Except threading doesn't work that way. The compiler /must/ be
>>>threading aware. It needs to know that it may not move code in certain
>>>directions past certain kinds of primitives, like pthread_mutex_lock.
>> 
>> Actually, the compiler doesn't know for beans what a function
>> called 'pthread_mutex_lock' does, or requires.   The C standard
>> has certain rules about moving code about, and one of them is that
>> code cannot be moved around a sequence point.
>
> That's wrong. Optimising compilers move code around sequence points all
> the time. They wouldn't be able to do much optimisation if they
> didn't.

[...]

> The main significance of sequence points in C is that modifying an lvalue
> more than once between sequence points results in undefined behaviour
> (e.g. "x = ++x;" is undefined because it modifies x twice without an
> intervening sequence point).

This isn't true. 'Sequence points' are used to put sequencing
constraints on expression evaluation, specifically

	Evaluation of an expression may produce side effects. At
	certain specified points in the execution sequence called
	sequence points, all side effects of previous evaluations
	shall be complete and no side effects of subsequent
	evaluations shall have taken place.
        [ISO/IEC 9899:1999 (E), 5.1.2.2.3|2]

And strictly speaking, this implies that 'object accesses' may be
moved freely around sequence points because they are (in absence of a
volatile qualifier) not side effects. Assuming the following code
snippet:

	int a;
        pthread_mutex_t lock;

        int get_a(void)
        {
        	int b;
                
        	pthread_mutex_lock(&lock);
                b = a;
                pthread_mutex_unlock(&lock);

                return b;
	}                

A compiler may peform the access to a which determines the value
returned by the function at any convenient time, as per the rule
quoted above, irregardless of any intervening function calls. In
practice, of course, compilers don't do that and that's why volatile
isn't really necessary in this case (except insofar 'deathstation
5000' scenarios are discussed).

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

#806

Rainer Weikusat <rweikusat@mssgmbh.com> writes:

>And strictly speaking, this implies that 'object accesses' may be
>moved freely around sequence points because they are (in absence of a
>volatile qualifier) not side effects. Assuming the following code
>snippet:

>	int a;
>        pthread_mutex_t lock;

>        int get_a(void)
>        {
>        	int b;
>                
>        	pthread_mutex_lock(&lock);
>                b = a;
>                pthread_mutex_unlock(&lock);

>                return b;
>	}                

>A compiler may peform the access to a which determines the value
>returned by the function at any convenient time, as per the rule
>quoted above, irregardless of any intervening function calls. In
>practice, of course, compilers don't do that and that's why volatile
>isn't really necessary in this case (except insofar 'deathstation
>5000' scenarios are discussed).

Except, of course, that the compiler *cannot* move the access to
the object "a" before pthread_mutex_lock or after pthread_mutex_unlock
because the kernel cannot know whether the object "a" can be changed
by those functions.

The compiler can do that *only* if it can determine that the object "a"
cannot be changed.  It may do so, e.g., when object "a" is declared
as "static" and there are no functions setting "a" (or take the address
of "a" etc) in the compilation unit.

Casper
-- 

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

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

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

csiph-web