Prev: Continuation of the MacOS networking thread...
Next: Continuation of the MacOS networking thread...
From: David Schwartz on 23 Dec 2009 14:20
On Dec 23, 9:23 am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:

> Not that this would really matter for the core parts of my
> statement. So, where are your (or anyone else's) examples for
> non-fictional platforms with non-atomic 'int/ unsigned' memory
> accesses? This is, after all, information which could be of use, while
> hand-waiving generally isn't.

That's sheer idiocy. Perhaps you consider it acceptable to write code
that crashes or fails in subtle ways when someone upgrades their CPU
or operating system, but I don't. Today's code is written to run
*reliably* on tomorrow's CPUs as well.

DS
From: Scott Lurndal on 23 Dec 2009 14:42
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 ?
>

Why? sig_atomic_t's significant characteristic is the volatile keyword.

There are many reasons that the "x++;" statement in the OP should
be avoided; the primary reason being cache contention. You'll get
no speedup from the additional threads if they all need to access
the same cache line. Might as well just use one thread.

One must also worry about compiler reordering (for which volatile can be
of some limited use) and C Language sequence points as well as atomicity.

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.)

One must also be aware of platform load and store memory ordering and use the
appropriate barriers (again, the __sync* builtins in gcc handle this for you).

scott
From: Rainer Weikusat on 23 Dec 2009 14:45
David Schwartz <davids(a)webmaster.com> writes:
> On Dec 23, 9:23�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote:
>
>> Not that this would really matter for the core parts of my
>> statement. So, where are your (or anyone else's) examples for
>> non-fictional platforms with non-atomic 'int/ unsigned' memory
>> accesses? This is, after all, information which could be of use, while
>> hand-waiving generally isn't.
>
> That's sheer idiocy.

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.
From: Rainer Weikusat on 23 Dec 2009 14:45
Golden California Girls <gldncagrls(a)aol.com.mil> writes:
> 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.

In absence of other information, that's a reasonable assumption.
From: Rainer Weikusat on 23 Dec 2009 14:52
David Schwartz <davids(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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Continuation of the MacOS networking thread...
Next: Continuation of the MacOS networking thread...