|
Boost : |
From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-09-21 19:34:20
> On Tue, 21 Sep 2004 17:37:03 +0200, Alexander Terekhov <terekhov_at_[hidden]> wrote:
>
> Matt Hurd wrote:
> First off, atomocity without memory ordering and visibility protocol
> is pretty useless.
For many, perhaps most, tasks yes. However, think of a database
without locking... it can still be useful with optimistic concurrency
for some styles of application. Atomic memory transactions are just a
guarantee that the "bits" are consistent. Adding further guarantees
slows performance for the ordering or visibility guarantees that you
add. So for minimizing resource usage and maximising performance
where optimistic concurrency is a good enough quality of service
boost::memory_atomic might be enough, but perhaps the potential for
misuse is just too great. Maybe
boost::really_dangerous_memory_atomicity_guarantee<T> is a more
appropriate name ;-)
I can imagine a taxonomy of quality of service guarantees, all with
different performance tradeoffs, that are applicable to a C++ program
writer for concurrency, which eminent people over on std.c++ seem to
be tackling in some form. Consistency, atomicity, and different
strengths of visibilty and ordering seem to be the main issues, but
then again I didn't know till a week or two ago that some platforms
had as many as 15 different explicit operations for memory fencing
which makes me feel like a rather old babe in the woods.
This is beyond the point I was originally pursuing of how best to
organise code for platform specific architectures. Whatever works and
survives a review I guess is the practical answer...
Regards,
Matt Hurd
matthurd_at_[hidden]
www.hurd.com.au
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk