Re: SUSv3's "memory location" and threads

[John Love-Jensen <eljay at adobe dot com>]

Hi Adam,

I ran into that problem on a DEC Alpha machine, which could not access a
byte of memory but rather had to do a word (32-bit) of memory for
reads/writes and mask/shift (compiler generated, behind the scenes & under
the covers).

We worked around the problem by doing something like this:

struct { int foo; int bar[3]; };

Both foo and bar contained char data, but the int size (32-bit) was used to
avoid the coalescing issue during threaded access.

C (ISO 9899) and C++ (ISO 14882) both neglected threading as part of the
language specification.

I'm not sure of the details, but I presume the intentional oversight has to
do with vagaries of platform differences and the strong imperative in C/C++
to be competitively efficient with lovingly handcrafted assembly and
Fortran.  And, I presume, some push back from compiler vendors and OS
manufacturers.

Alas.

In my opinion, C and C++ are just not the best languages for threading*.
Java is better (but there are plenty of criticisms of the Java threading
model out there, q.v. Google).  Ada is even better, but appears to have
limited (buzzspeak alert!) mind-share in the broad developer community.

HTH,
--Eljay

* I've been doing threading in C++ for over 10 years, using an assortment of
threading "bolt-on" facilities.  All of them come up short -- but to their
credit they've all done the best they could (much better than I could have
created, I warrant!) given the context.