This is the mail archive of the
mailing list for the glibc project.
Re: malloc patch for 2.2.4
Wolfram Gloger <Wolfram.Gloger@dent.med.uni-muenchen.de> writes:
|> First, the ANSI/ISO standard for C still doesn't contain the word
|> thread or concurrency, so to argue on this base is questionable in any
Anything that is not explicitly specified in the standard is undefined by
default. The compiler is free to do _anything_ in such a case.
|> My point was that it would be _bad_ to enable such a
|> re-read in the compiler. It would seriously limit C's usefulness and
|> expressive power for threaded programming IMHO.
If you want to write a threaded program, you must program with thread
safety in mind. That means using mutexes where it matters. There is
nothing else that can garantee atomicity.
|> Second, I just discovered this in my draft of C9X:
|> 188.8.131.52 Program execution
|> [#5] An instance of each object with automatic storage
|> duration is associated with each entry into its block. Such
|> an object exists and retains its last-stored value during
|> the execution of the block and while the block is suspended
|> (by a call of a function or receipt of a signal).
|> Doesn't this forbid a re-read from 'a' for 'tmp' even in the
|> single-thread, but possibly signal-interrupted case?
No, a signal handler is only allowed to write to objects of type "volatile
Andreas Schwab "And now for something
SuSE Labs completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5