Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #673 > unrolled thread
| Started by | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| First post | 2011-05-31 21:07 +0200 |
| Last post | 2011-06-07 14:55 -0700 |
| Articles | 20 on this page of 102 — 16 participants |
Back to article view | Back to comp.unix.programmer
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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-15 13:20 +0100 |
| Message-ID | <87r56vi8vi.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #806 |
Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
>> 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.
Playing devil's advocate for the moment: Since pthread_mutex_lock is a
standardized function, the compiler might know that it won't
change a (this would, of course, basically amount to active sabotage
on behalf of the implementor but AFAIK, it isn't explicltly
prohibited).
[toc] | [prev] | [next] | [standalone]
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-06-15 13:19 +0000 |
| Message-ID | <4df8b14d$0$49041$e4fe514c@news.xs4all.nl> |
| In reply to | #808 |
Rainer Weikusat <rweikusat@mssgmbh.com> writes: >>>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. >Playing devil's advocate for the moment: Since pthread_mutex_lock is a >standardized function, the compiler might know that it won't >change a (this would, of course, basically amount to active sabotage >on behalf of the implementor but AFAIK, it isn't explicltly >prohibited). No, no, that won't work! Seem in the *C* standard pthread_mutex_lock() isn't standardized so it can't hoist the assignment. But if it *knows* about pthread_mutex_lock() is MUST know about threads and in that case it can only hoist the assignment if it can proof that there can not be another assignment. Casper --
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-06-15 17:41 +0100 |
| Message-ID | <pan.2011.06.15.16.40.50.63000@nowhere.com> |
| In reply to | #808 |
On Wed, 15 Jun 2011 13:20:33 +0100, Rainer Weikusat wrote: > Playing devil's advocate for the moment: Since pthread_mutex_lock is a > standardized function, the compiler might know that it won't > change a The compiler doesn't know which libraries you are going to link against. It cannot assume that you're going to be linking against the "official" unmodified libpthread, with a known implementation of pthread_mutex_lock(). If you look at how "intrinsics" are implemented, it relies upon the header file defining (or redirecting) the function as some __builtin_function() which the compiler recognises. If you desire, you can override the definition to cause the function to be a normal external reference which will be resolved by the libraries which are loaded at run time. And if the compiler /did/ know about pthread_mutex_lock(), it would know that calling it would block until the lock was released, and that whichever thread was holding the lock might modify "a" in the meantime. Even declaring "a" as "static" wouldn't help here, as the other thread might be running some function (in the same source file) which modifies "a".
[toc] | [prev] | [next] | [standalone]
| From | David Schwartz <davids@webmaster.com> |
|---|---|
| Date | 2011-06-15 20:20 -0700 |
| Message-ID | <79391654-9544-4ba6-a4e3-1025613fc8a9@z7g2000prh.googlegroups.com> |
| In reply to | #808 |
On Jun 15, 5:20 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > Playing devil's advocate for the moment: Since pthread_mutex_lock is a > standardized function, the compiler might know that it won't > change a (this would, of course, basically amount to active sabotage > on behalf of the implementor but AFAIK, it isn't explicltly > prohibited). It is impossible to know something that is not true. If the compiler does not know what the function does, it cannot make assumptions about what it does or it is broken. If the compiler does know what the function does, anything it does based on this correct knowledge is necessarily safe. If your point is that a compiler may require specific changes, including removing some optimizations, to support threaded code, you are of course correct. DS
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-06-15 17:31 +0100 |
| Message-ID | <pan.2011.06.15.16.31.18.172000@nowhere.com> |
| In reply to | #805 |
On Wed, 15 Jun 2011 10:22:32 +0100, Rainer Weikusat wrote:
>> 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.
This doesn't mean what you are suggesting that it means. The standard
specifies the behaviour of an abstract machine. The compiler can generate
code as it sees fit so long as the end result is "as if" the side effects
occurred in the specified order.
> 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.
Anything may be moved freely around sequence points so long as the
difference isn't observable according to the rules of the language. It
doesn't matter whether or not the difference is observable by means which
are outside the scope of the language, e.g. multi-threading or
memory-mapped hardware.
> 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.
This is incorrect. The compiler cannot know whether ptread_mutex_lock()
modifies "a". If you were to add "static", it would be different, provided
that there wasn't a "some_external_func(&a);" call anywhere in the
translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-15 18:31 +0100 |
| Message-ID | <87tybrngqz.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #810 |
Nobody <nobody@nowhere.com> writes:
> On Wed, 15 Jun 2011 10:22:32 +0100, Rainer Weikusat wrote:
>>> 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.
>
> This doesn't mean what you are suggesting that it means.
I'm not 'suggesting' anything. The text says this.
[...]
>> 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.
>
> Anything may be moved freely around sequence points so long as the
> difference isn't observable according to the rules of the language.
The only thing which is 'observable, according to the rules of the
language' is the output written to files after program
termination. Since the C standard doesn't require anything particular
wrt program execution time, especially, it doesn't require that a
program terminates after a finite amount of time has passed, a C
compiler can just generally ignore any input and only omit code for an
single, endless loop: This is fine because - as I already mentioned -
termination after a finite amount of time has passed isn't required
and since the program never terminates, it cannot have any observable
effects, either.
>> 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.
>
> This is incorrect. The compiler cannot know whether ptread_mutex_lock()
> modifies "a".
Given that, as you demonstrated above, any C program is semantically
equivalent to
while (1);
wether or not a is ever modified doesn't really matter. Also, given
that, according to you, side effects are not supposed to occur in any
particular order, generating code equivalent to
pthread_mutex_unlock(&lock);
pthread_mutex_lock(&lock);
return b;
b = a;
ought to be fine.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-15 13:32 -0700 |
| Message-ID | <511f80c3-5f3f-43ba-bd55-11e66f30d0ba@z7g2000prh.googlegroups.com> |
| In reply to | #812 |
On Jun 15, 10:31 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > Nobody <nob...@nowhere.com> writes: > > On Wed, 15 Jun 2011 10:22:32 +0100, Rainer Weikusat wrote: > >> 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. > > > Anything may be moved freely around sequence points so long as the > > difference isn't observable according to the rules of the language. > > The only thing which is 'observable, according to the rules of the > language' is the output written to files after program > termination. Since the C standard doesn't require anything particular > wrt program execution time, especially, it doesn't require that a > program terminates after a finite amount of time has passed, a C > compiler can just generally ignore any input and only omit code for an > single, endless loop: This is fine because - as I already mentioned - > termination after a finite amount of time has passed isn't required > and since the program never terminates, it cannot have any observable > effects, either. Actually, a couple of things here. I don't know the C standard that well offhand, but I bet it mimics the C++ standard in this regard. Specifically, volatile object accesses are also "observable behavior" in an implementation defined way. Also, interactive IO is part of the observable behavior, such as stdin and stdout, but again in an implementation defined way. And IIRC the implementation is free to add additional functions which constitute interactive IO or such, such as network IO, which also become observable behavior, in an implementation defined way. Note that even what constitutes a "file" is implementation defined. Now, you are right that a malicious implementation can do lots of nasty things. I find it's not worth anyone's time to talk about malicious implementations. We're going to assume non-malicious implementations for the rest of the discussion. If it is malicious, then the game is already over. You've lost, and it's time to switch to a new implementation.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-15 22:19 +0100 |
| Message-ID | <8739jau71f.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #812 |
Rainer Weikusat <rweikusat@mssgmbh.com> writes: [...] > Given that, as you demonstrated above, any C program is semantically > equivalent to > > while (1); > > wether or not a is ever modified doesn't really matter. Just in case this isn't clear on its own: In my opinion, this is an absurd interpretation of the standard text which was constructed by exploiting semantic ambiguities of that with as much technical malevolence as possible (similar to my remark about read access reordering across function calls, actually, except that I won't claim that this malevolent interpretation is anyhow close to the intended meaning of the text). It is not possible to determine if the option for this malevolent interpretation exists intentionally but because of concerns of pratical usability, the possibility can be disregarded.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-06-16 05:02 +0100 |
| Message-ID | <pan.2011.06.16.04.01.37.594000@nowhere.com> |
| In reply to | #812 |
On Wed, 15 Jun 2011 18:31:32 +0100, Rainer Weikusat wrote:
>>> 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.
>>
>> This doesn't mean what you are suggesting that it means.
>
> I'm not 'suggesting' anything. The text says this.
I'm not disputing what it says, but you are trying to assign a meaning
which does not exist.
>> Anything may be moved freely around sequence points so long as the
>> difference isn't observable according to the rules of the language.
>
> The only thing which is 'observable, according to the rules of the
> language' is the output written to files after program
> termination.
You're overlooking "external linkage"; 5.1.2.3p10:
[#10] Alternatively, an implementation might perform various
optimizations within each translation unit, such that the
actual semantics would agree with the abstract semantics
only when making function calls across translation unit
boundaries. In such an implementation, at the time of each
function entry and function return where the calling
function and the called function are in different
translation units, the values of all externally linked
objects and of all objects accessible via pointers therein
would agree with the abstract semantics. Furthermore, at
the time of each such function entry the values of the
parameters of the called function and of all objects
accessible via pointers therein would agree with the
abstract semantics. In this type of implementation, objects
referred to by interrupt service routines activated by the
signal function would require explicit specification of
volatile storage, as well as other implementation-defined
restrictions.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-14 23:23 -0700 |
| Message-ID | <fae9f105-651b-4505-aeea-0467efa1a57d@l14g2000pro.googlegroups.com> |
| In reply to | #800 |
On Jun 14, 2:43 pm, sc...@slp53.sl.home (Scott Lurndal) wrote: > Joshua Maurice <joshuamaur...@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). This is simply incorrect. The compiler must be threading aware, through purposeful action or by luck. As explained else-thread, a (C or C++) compiler is well within its rights to rearrange code however it wants, as long as the end result is one of the allowed executions. In C++, this is clearly spelled out in the "as if" rule of 1.9 Program execution / 1. In C, this is still pretty spelled out in 5.1.2.3 Program execution. If the compiler did not know about threads, and optimized aggressively, it could move code the wrong way past a pthread_mutex_lock, which would break everything. This is one of the compelling reasons to put threading into the actual language standard. It cannot be implemented as a library.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-15 10:12 +0100 |
| Message-ID | <87oc1zbgqv.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #759 |
Joshua Maurice <joshuamaurice@gmail.com> writes: > 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. [...] > Volatile is neither necessary nor sufficient for inter- > thread communication (except maybe win32). [...] > and the stronger statement that if you're trying to use > volatile for inter-thread communication then your program has > undefined behavior [...] > 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. [NB: I've rearranged the original text in order to get this sequence of "threading!", "threading!", "threading!" "how can you claim I'd be wrongly concerned with threading?"]. In this case, I think I can enlighten you somewhat: The reason why I keep pointing out that volatile is not related to threading, despite what you apparently believe, is because you keep babbling about threading while ignoring my attempts to inform you about the fact that 'volatile' changes the expression evaluation rules laid out in the C standard in a certain way. These changes are theoretically necessary whenever 'accessing an object' is not an idempotent operation for some reason the/a compiler cannot determine on its own. This may occur in multithreaded programs, among other cases.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-15 02:53 -0700 |
| Message-ID | <de604fb2-f616-4899-910e-aca06adf939d@22g2000prx.googlegroups.com> |
| In reply to | #804 |
On Jun 15, 2:12 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > > > 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. > > [NB: I've rearranged the original text in order to get this sequence > of "threading!", "threading!", "threading!" "how can you claim I'd be > wrongly concerned with threading?"]. > > In this case, I think I can enlighten you somewhat: The reason why I > keep pointing out that volatile is not related to threading, despite > what you apparently believe, is because you keep babbling about > threading while ignoring my attempts to inform you about the fact that > 'volatile' changes the expression evaluation rules laid out in the C > standard in a certain way. These changes are theoretically necessary > whenever 'accessing an object' is not an idempotent operation for some > reason the/a compiler cannot determine on its own. This may occur in > multithreaded programs, among other cases. I'll make my reply short, as we're just repeating ourselves now. "These changes are theoretically necessary" only according to a theory that no one else practices. The compiler writers do not endorse this theory. The C standard writers, the POSIX standard writers, and the C+ +0x standard writers, do not endorse this theory. The experts do not endorse this theory. As a matter of factual information, this theory is demonstrably wrong on Linux gcc and (nearly?) all other unix-like platforms. In short: you are wrong. Volatile is not necessarily required when the memory actions are not "idempotent". Specifically, volatile is not required for correct thread code, nor is it sufficient for correct thread code.
[toc] | [prev] | [next] | [standalone]
| From | David Schwartz <davids@webmaster.com> |
|---|---|
| Date | 2011-06-08 10:19 -0700 |
| Message-ID | <17a4bc52-a36b-4451-8715-c56eca0efc4a@d26g2000prn.googlegroups.com> |
| In reply to | #757 |
On Jun 7, 8:05 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > 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 that the threading standard is not "completely orthogonal". The threading standard is not language-independent and code written to the threading standard need not conform to the C standard so long as it conforms to the C standard as modified by the threading standard. I admit that it might be theoretically possible to create such a threading standard. But to my knowledge, no such threading standard exists for very good reasons -- performance would be awful. DS
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-10 16:50 +0100 |
| Message-ID | <871uz13ctc.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #770 |
David Schwartz <davids@webmaster.com> writes: > On Jun 7, 8:05 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: >> 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 that the threading standard is not "completely orthogonal". The > threading standard is not language-independent and code written to the > threading standard need not conform to the C standard so long as it > conforms to the C standard as modified by the threading standard. The UNIX(*) standard incorporates the C standard by reference and at least, I wasn't able to find any exception rule for the C rules for evaluating expressions in the former. > I admit that it might be theoretically possible to create such a > threading standard. But to my knowledge, no such threading standard > exists for very good reasons -- performance would be awful. I do not quite understand why 'performance would be awful' just because source-code level read accesses to some objects must have a 1:1 correspondence with such accesses in the generated machine code. ?
[toc] | [prev] | [next] | [standalone]
| From | David Schwartz <davids@webmaster.com> |
|---|---|
| Date | 2011-06-15 20:24 -0700 |
| Message-ID | <1913c64a-d2d2-42c4-b4eb-11855e54b158@r27g2000prr.googlegroups.com> |
| In reply to | #778 |
On Jun 10, 8:50 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > > I admit that it might be theoretically possible to create such a > > threading standard. But to my knowledge, no such threading standard > > exists for very good reasons -- performance would be awful. > I do not quite understand why 'performance would be awful' just > because source-code level read accesses to some objects must have a > 1:1 correspondence with such accesses in the generated machine code. It wouldn't just be "some objects", it would be effectively all objects. Many applications work such that the majority of their data can be worked on by more than one thread. It would also mean either that you would have to identify all data that might be access by more than one thread or treat all data as volatile. Both possibilities are impractical. It would also mean that code that "just happened to be" single-threaded at the moment would perform differently from code that designed to be single-threaded, which would be a horrible trade-off, especially since you're wouldn't gain anything by doing things that way. In practice, 'volatile' has no use for threading. It's not necessary, it's not sufficient, it's not practical to determine where you need it and where you don't, and it saps performance for no benefit. It is, however, quite useful for the specific applications given in the C standard. DS
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-16 22:11 +0100 |
| Message-ID | <87boxx7a7z.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #817 |
David Schwartz <davids@webmaster.com> writes: > On Jun 10, 8:50 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > >> > I admit that it might be theoretically possible to create such a >> > threading standard. But to my knowledge, no such threading standard >> > exists for very good reasons -- performance would be awful. > >> I do not quite understand why 'performance would be awful' just >> because source-code level read accesses to some objects must have a >> 1:1 correspondence with such accesses in the generated machine code. > > It wouldn't just be "some objects", it would be effectively all > objects. Many applications work such that the majority of their data > can be worked on by more than one thread. For as long as there are not n threads working on the same data in parallell (eg, 2 threads using a lockless ring buffer implemented with the help of __sync_synchronize of whatever architecture-specific memory barrier instructions are available), there shouldn't be any issues caused by the running code not evaluating every object access which happened to be in the source code. 'volatile' really just changes the C expression evaluation rules and nothing else. Using another contrived example, it communicates that, given an object defined as int a; completely evaluating a + a might yield a different result than just doing a << 1 instead would. [...] > In practice, 'volatile' has no use for threading. Provided that multi-threaded programs are written in C, the expression evaluated by their threads are evaluated according to the same rules which always apply to that and consequently, the same changes to these rules might be needed for the same reasons as in the single-threaded case. Technically, all C programs are theoretically multi-threaded because of the existence of signal handlers, which provide classic 'preemptive multitasking' by multiplexing a single 'execution resource' among multiple 'code streams' based on specific events (such as 'a specific amount of time has passed'). > It's not necessary, it's not sufficient, it's not practical to > determine where you need it and where you don't, and it saps > performance for no benefit. First and foremost IT IS NOT AN INTER-THREAD SYNCHRONIZATION PRIMITVE OF ANY SHAPE, SIZE OR COLOUR, dammit. It cannot be that difficult to understand a simple fact like that ...
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-17 04:43 -0700 |
| Message-ID | <6d625d6a-9667-4d01-b281-99b8edfa5790@l2g2000prg.googlegroups.com> |
| In reply to | #824 |
On Jun 16, 2:11 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > > For as long as there are not n threads working on the same data in > parallell (eg, 2 threads using a lockless ring buffer implemented with > the help of __sync_synchronize of whatever architecture-specific > memory barrier instructions are available), there shouldn't be any > issues caused by the running code not evaluating every object access > which happened to be in the source code. 'volatile' really just > changes the C expression evaluation rules and nothing else. Using > another contrived example, it communicates that, given an object > defined as > > int a; > > completely evaluating a + a might yield a different result than just > doing a << 1 instead would. Yes. It might. You have no way of doing anything useful with this knowledge portably and reliably (apart from signal handlers and setjump/longjump). > > In practice, 'volatile' has no use for threading. > > Provided that multi-threaded programs are written in C, the expression > evaluated by their threads are evaluated according to the same rules > which always apply to that and consequently, the same changes to these > rules might be needed for the same reasons as in the single-threaded > case. Technically, all C programs are theoretically multi-threaded > because of the existence of signal handlers, which provide classic > 'preemptive multitasking' by multiplexing a single 'execution > resource' among multiple 'code streams' based on specific events (such > as 'a specific amount of time has passed'). You are really conflating threading and true concurrency with preemption and signal handlers? No... just no. > > It's not necessary, it's not sufficient, it's not practical to > > determine where you need it and where you don't, and it saps > > performance for no benefit. > > First and foremost IT IS NOT AN INTER-THREAD SYNCHRONIZATION PRIMITVE OF ANY > SHAPE, SIZE OR COLOUR, dammit. It cannot be that difficult to > understand a simple fact like that ... I must say, I am feeling the same way about you whenever you say something about "volatile" and "volatile really just changes the C expression evaluation rules and nothing else". You are wrong. You think you know something about the C standard, specifically the meaning of volatile, but you are mistaken. I say again, volatile is only for communicating between regular code and signal handler code (with sig_atomic_t), and for communicating across setjump longjump pairs. Any other use of volatile does nothing portably and reliably besides making your code run slower. This is a simple matter of demonstrable fact about the current compilers available, and this is a simple demonstrably held opinion by basically all of the people on the C standards committee, the C++ standards committee, the POSIX guys, and all of the compiler writers. It does not matter "what it means" when all of those people are against you. Continue to stick your head in the ground, being delusional, or accept the broad community's understanding of the terms and/or effect of the document. I have no other recourse in a definitional argument like this. (I'm not sure why I'm even responding at this point. Oh well. Duty calls. http://xkcd.com/386/ )
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-19 01:43 -0700 |
| Message-ID | <rubrum-12F8FC.01432519062011@news.albasani.net> |
| In reply to | #827 |
In article <6d625d6a-9667-4d01-b281-99b8edfa5790@l2g2000prg.googlegroups.com>, Joshua Maurice <joshuamaurice@gmail.com> wrote: [...] Not knowing any of the fine points of the discussion and basing my assessment upon other cues, I think you must have the right of it. > (I'm not sure why I'm even responding at this point. Oh well. Duty > calls. > http://xkcd.com/386/ > ) And upon that assessment going to xkcd is as using a wood chisel to open a locked desk drawer: neither is at their best when you finish, and what have you accomplished? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-06-19 13:35 +0100 |
| Message-ID | <87pqma0ziq.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #830 |
Michael Press <rubrum@pacbell.net> writes: > In article > <6d625d6a-9667-4d01-b281-99b8edfa5790@l2g2000prg.googlegroups.com>, > Joshua Maurice <joshuamaurice@gmail.com> wrote: > > > [...] > > Not knowing any of the fine points of the discussion > and basing my assessment upon other cues, I think you > must have the right of it. Insofar all kinds of 'paper decrees' are naively considered, I would agree with this presumption. Insofar actual multi-threaded programming of current (SMP) hardware both in applications and in OS kernels is concerned, I claim that this isn't (and was never) done according to some set of possible future C and C++ language standards. >> (I'm not sure why I'm even responding at this point. Rest assured that I won't see it :->.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-19 17:06 -0700 |
| Message-ID | <cd62448e-055c-4b01-8068-30b632a2dfbc@q14g2000prh.googlegroups.com> |
| In reply to | #831 |
On Jun 19, 5:35 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > Michael Press <rub...@pacbell.net> writes: > > In article > > <6d625d6a-9667-4d01-b281-99b8edfa5...@l2g2000prg.googlegroups.com>, > > Joshua Maurice <joshuamaur...@gmail.com> wrote: > > > [...] > > > Not knowing any of the fine points of the discussion > > and basing my assessment upon other cues, I think you > > must have the right of it. > > Insofar all kinds of 'paper decrees' are naively considered, I would > agree with this presumption. Insofar actual multi-threaded programming > of current (SMP) hardware both in applications and in OS kernels is > concerned, I claim that this isn't (and was never) done according to > some set of possible future C and C++ language standards. > > >> (I'm not sure why I'm even responding at this point. > > Rest assured that I won't see it :->. Well, for the benefit of others, I will simply point out the straw man that you are attacking. In nearly every post in this thread, I have cited not merely only future C and C++ standards. I have also cited the POSIX pthreads standard, every C expert, every C++ expert, every C and C++ compiler writer, and the demonstrable facts about past and current compilers, as the basis of my claim that you're doing it wrong.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web