multi-threaded data access
in [Unix Programming]
|
Prev: Continuation of the MacOS networking thread...
Next: Continuation of the MacOS networking thread...
From: Scott Lurndal on 23 Dec 2009 16:50 Rainer Weikusat <rweikusat(a)mssgmbh.com> writes: >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. I'll point out: 1) The O.P. used 'x++' which is a read-modify-write cycle. 2) For the problem posed by the O.P. more threads than cores makes little sense, so the O.P. also implicitly assumed a multiprocessor system. scott
From: David Schwartz on 23 Dec 2009 19:26 On Dec 23, 1:32 pm, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > What is (by definition) outside the domain of an API-specification > based on C 'function calls' cannot ever be part of it ... Yes, and this question is 100% inside the domain of the API specification. The API specifies under what cases operation have defined results and under what cases they don't. > > 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. You've really lost your mind. And you do a major disservice to people who listen to you. DS
From: Barry Margolin on 23 Dec 2009 21:00 In article <87fx72vv9e.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > David Schwartz <davids(a)webmaster.com> writes: > > On Dec 22, 4:09�pm, "novicki...(a)gmail.com" <novicki...(a)gmail.com> > > wrote: > >> lets say I have > >> > >> unsigned int x = 0; > >> > >> And the code > >> > >> x++; > >> > >> Is run a total of 1 million times but the million times is divided > >> across many threads. > >> > >> If i try to read the value of x am i guaranteed to get a value between > >> 0 and 1 million. > > > > No, at least not unless some document provides such a guarantee. > > A standard is a specification of requirements and as such, doesn't > "guarantee" anything. Insofar a test suite exists and a particular > platform was found to be compliant, that would be sort-of a guarantee > (the test suite itself could be buggy). Well, a claim of conformance to a standard is considered to be a guarantee that all its requirements are met. If it doesn't actually meet the guarantees, it's a bug. But that's as good a guarantee you're going to get in anything computer-related. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Barry Margolin on 23 Dec 2009 21:06 In article <87vdfxbdic.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > 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. But POSIX *could* specify that the compiler must automatically generate the necessary mutual exclusion to ensure that the operation works atomically if the hardware doesn't ensure this. That's one of the things operating systems and programming languages do, they hide the details of the hardware and provide a common abstraction. However, POSIX doesn't have such a requirement, so it ends up being hardware-dependent. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: novickivan on 23 Dec 2009 23:23
On Dec 23, 7:59 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > Eric Sosman <esos...(a)ieee-dot-org.invalid> writes: > > On 12/23/2009 8:33 AM, Rainer Weikusat wrote: > >> Eric Sosman<esos...(a)ieee-dot-org.invalid> writes: > >>> On 12/23/2009 5:24 AM, Rainer Weikusat wrote: > >>>> "novicki...(a)gmail.com"<novicki...(a)gmail.com> writes: > The OP is using Mac OS X on Intel and this means the answer is 'yes' > for him, subject to the limitations I already wrote about, eg, > accesses crossing cacheline boundaries. This is also true for all > other OSes running on x86 platforms and for all other hardware/ > software combinations I am aware of. Just for the record, my primary platform is x86 using various OS's. Sparc is also of some interest even though it is the minority case. Cheers, Ivan Novick |