Re: C++ Threads, what's the status quo?
Thomas Richter wrote:
This is actually the motivation of most of my posts: to remind us that
all trickery will ultimately lead to kernel-mode synchronization
primitives.
Not necessarely, and not ultimately. On some architectures, you can
write a simple mutex with spinlock functionality just with atomic
increments and decrements. Depending on the architecture and the
application, this might be a considerably useful design.
It is useful. It is useful in cases where it is appropriate do to
spin-locking, like in the Windows NDIS device driver I was working on a
year ago
NdisAllocateSpinLock(pLock)
NdisFreeSpinLock(pLock)
NdisAcquireSpinLock(pLock)
NdisReleaseSpinLock(pLock)
Spin-locking is a bit like vertical-take-off-and-landing (VTOL) in jet
aircraft. Yes, if you use it, it will allow you to go vertical as
would a helicopter, but you had better not spend to much time doing it
or the penalty will be severe. In general, it is not appropriate to
spin. The situations where it is appropriate is a mall fraction of the
cases that a C++ programmer will encounter in typical user-mode code.
Generalized data structures in user-mode code will still require
synchronization, the kind that has been understood for 30+ years, One
function will have to enter a full-blown wait state while the other
does its work.
It should be evident from this thread that there are at least a few
readers who have either soft or hard expectations that tweaking C++
somehow will replace this necessity. This is not going to happen.
[I am not saying that you, in particular, are one of the people
hoping.]
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]