This is the mail archive of the
libc-alpha@sources.redhat.com
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
|> direction.
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:
|>
|> 5.1.2.3 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
sig_atomic_t".
Andreas.
--
Andreas Schwab "And now for something
SuSE Labs completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5