This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc patch for 2.2.4

Wolfram Gloger <> 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:
|>  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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]