multi-threaded data access
in [Unix Programming]
|
Prev: Continuation of the MacOS networking thread...
Next: Continuation of the MacOS networking thread...
From: Eric Sosman on 23 Dec 2009 16:01 On 12/23/2009 1:21 PM, Golden California Girls wrote: > Rainer Weikusat wrote: >> >> No I didn't, as you are very well aware. The relevant header which >> came with the original posting was >> >> X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) >> AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.43 Safari/532.5,gzip(gfe),gzip(gfe) >> > > Which just means he has a Mac, it in no way implies that is the machine he is > writing code for. Nor, even if he is in fact writing for that machine at the moment, does it mean that he's interested only in that machine. He did *not* specify any particular O/S, he did *not* specify any particular hardware, he did *not* specify any particular library or threading standard/framework or anything else. The *only* available inference is that since he asked the question in comp.unix.programmer he is presumably interested in flavors of Unix-allied systems. And that's all. No further information was provided to specialize the query. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Rainer Weikusat on 23 Dec 2009 16:12 scott(a)slp53.sl.home (Scott Lurndal) writes: > Ralph =?UTF-8?Q?B=C3=B6hme?= <ralph-nsp(a)rsrc.de> writes: >>Eric Sosman <esosman(a)ieee-dot-org.invalid> schrieb: >>> On 12/23/2009 5:24 AM, Rainer Weikusat wrote: >>>> "novickivan(a)gmail.com"<novickivan(a)gmail.com> writes: >>>>> [...] >>>>> The subtle question here is, are reads and writes of a variable >>>>> atomic? >>>> >>>> The short answer is 'yes'. >>> The short answer is "maybe." >> >>I guess the helpful short answer is sig_atomic_t ? [...] > While glibc documentation may imply that accesses to 'int' are "generally" > atomic, if your algorithm requires true atomicity, either protect the > variable with a pthread_mutex_t or use in-line assembly to generate the > locked prefix (later version of gcc support builtin atomic access functions, > such as __sync_fetch_and_add, etc. which automatically generate the > appropriate atomic instruction sequence for the architecture. See > info gcc.) The quoted text above is a question specifically relating to read and write operations on objects of type 'unsigned'. Not to read-modify-write-cycles. Not memory access ordering (or lack thereof) in multiprocessor systems. Not to all kinds of other things which COULD be more or less loosely related to conceivable reasons why one could ask such a question. And non-misaligned single-word loads or stores are atomic for all practical purposes. One could argue that this is a hardware-related question and thus, off-topic here. OTOH, even UNIX(*) runs on real computers.
From: David Schwartz on 23 Dec 2009 16:19 On Dec 23, 11:52 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > David Schwartz <dav...(a)webmaster.com> writes: > > On Dec 23, 2:29 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > >> > It depends what the documentation for the threading standard you are > >> > using says. If POSIX, you are not guaranteed anything at all, it could > >> > even crash. > >> This is a statement which goes beyond the realm of the standard, > >> meaning, either it describes an actual example, then this example > >> should be named, and otherwise, it is science fiction. > > Huh? The POSIX standard is quite clear that it puts no restrictions > > whatsoever on what an implementation can do in this case. > POSIX/ UNIX(*) is an API specification and not concerned with hardware > properties at that level. Right, but most UNIX programmers write hardware-independent code, so they don't care about the properties of specific hardware implementations. Do you see anything about the OP's question that suggests that he's way outside the norm? DS
From: David Schwartz on 23 Dec 2009 16:20 On Dec 23, 11:45 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > No. 'Idiocy', by its original definition, roughly means 'ignoring > facts in favor of preconceived opinions regarding how the world really > should have been instead'. Such as in persistently failing to mention > relevant examples in the domain this thread takes place, which is > 'properties of hardware memory models', in favor of fairy-tales based on > what particular documents don't say about topics they were never > supposed to cover. You have taken a perfectly routine UINX programming question and magically transformed it into a question about the details of specific hardware implementations. You are the one cramming this question into your ridiculous preconceived opinions. DS
From: Rainer Weikusat on 23 Dec 2009 16:32
David Schwartz <davids(a)webmaster.com> writes: > On Dec 23, 11:45�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: >> No. 'Idiocy', by its original definition, roughly means 'ignoring >> facts in favor of preconceived opinions regarding how the world really >> should have been instead'. Such as in persistently failing to mention >> relevant examples in the domain this thread takes place, which is >> 'properties of hardware memory models', in favor of fairy-tales based on >> what particular documents don't say about topics they were never >> supposed to cover. > > You have taken a perfectly routine UINX programming question and > magically transformed it into a question about the details of specific > hardware implementations. What is (by definition) outside the domain of an API-specification based on C 'function calls' cannot ever be part of it ... > You are the one cramming this question into > your ridiculous preconceived opinions. .... and your philosophical convictions as to what people should or shouldn't (be allowed) to know don't change this. Actually, that you are lacking the spine to argue in favor of your conviction that Programmers Must Be Blindfolded For The Good Of Us All, as evidenced by the fact that your only 'argument' in favor of your opinion is character assassination, serves as a strong point against it: One should naturally question what you have to loose when others learn what you yourself certainly know. |