On Tue, 21 Sep 2004 17:37:03 +0200, Alexander Terekhov <terekhov@web.de> 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@acm.org www.hurd.com.au