[boost] Re: Boost::thread feature request: thread priority

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-07-04 04:52:33

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: ... <3f05422b.305462221_at_newsvr>

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.