Maxim Egorushkin wrote:
[...]
> Seems like the issue is undefined behaviour when casting away volatile.
> Do I get it right?
Yes, UB is the issue ("one of the most obvious tips of the iceberg").
Well, more on volatiles (low level stuff) can be found below. Uhmm,
as for "higher level safety" (and also efficiency)... you might want
to take a look at ADA's "protected types" (and the "proxy model"):
http://groups.google.com/groups?threadm=3D7E18EB.BC80C2EB%40web.de
http://groups.google.com/groups?threadm=3D7E24FC.E1AE86B0%40web.de
(Subject: Re: POSIX Threads and Ada)
<Forward Inline>
-------- Original Message --------
Date: Fri, 04 Jul 2003 11:30:56 +0200
Newsgroups: comp.programming.threads
Subject: Re: Does anyone think 'volatile' is a platform-independent
way to make variable access thread safe?
References: ... <[EMAIL PROTECTED]>
Ziv Caspi wrote: ...
Ziv, "volatile" stuff IS brain-damaged. Really. kinda-<copy&paste>
Originally, C/C++ volatiles were indeed designed having memory mapped
I/O ("registers"/"ports") in mind. At that time hardware was rather
simplistic and didn't do any reordering in either "ordinal" or "I/O"
space. Modern hardware COULD reorder memory accesses in ALL spaces.
So, you basically need almost the same reordering constrains (see the
links below) for portable device driver programming as for threading.
The situation is actually kinda more complicated because for device
drivers you'd need to "control" BOTH spaces -- e.g. if you publish a
bunch of structure addresses and those structure meant to be
read/write by a device, you'll need to ensure "cross-space" ordering.
Unfortunately, the upcoming <iohw.h> and <hardware> still lacks
facilities (ala "msync" stuff -- pls see below) to do that... unless
they really want to impose "total ordering" if you use any read/write
IO calls.
Later, volatiles were kinda {re-}used for setjmp/longjmp stuff in
order to spill the locals to memory (and to reload them after the
jump). Finally, volatiles are also needed for static sig_atomic_t's.
Both these uses of volatiles are purely "single-threaded". Ideally,
we should get rid completely of setjmp/longjmp (ISO C should adopt
C++ exceptions... but after they will be repaired, of course) and
also asynchronous signals (threads shall replace them). Given the
upcoming <iohw.h> and <hardware>, C/C++ volatiles could then be
deprecated as well. Now, back to threading and C++... here's some
C++ code for "curious" folks who can "speak C++":
http://www.terekhov.de/pthread_refcount_t/experimental/refcount.cpp
Some wording about msync "semantics" can be found here:
http://www.google.com/groups?selm=3EE0CA46.593F938B%40web.de
(Subject: Re: Asynchronous queue without synchronization primitives)
Reference counting operation are described here:
http://www.terekhov.de/pthread_refcount_t/draft-edits.txt
Comments are quite welcome. TIA.
regards,
alexander.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
