true ... there have been some people mentioning this, it shouldn't be hard to implement dcas for boost.atomic. unfortunately neither helge nor me seem to use msvc and nobody with msvc wants to get his hands dirty to implement the specific part ...
I may give it a crack. At least on the 64bit platform. It should be pretty straight forward.
that would be great!
3. I also think it's important to provide size() method if only for monitoring purposes. (unsafe_size() maybe). Most people would want to take some action if the size of the queue exceed a reasonable (in their domain) limit.
this would have two issues: - it won't be accurate - it would either be expensive to call (O(n)) or introduce an overhead of an atomic operation per push/pop
I think it's ok on both points. You can't really rely on size() even if it were accurate. We take size samples every 10000 or so push'es to see if the queue is being backed up. As long as the cost of size() is well known and deterministic, I think it's worth having it.
hm, i can try to introduce a O(n) version ...
4. is_lock_free() should be a compile time check. I may want to chose a different queue if the lock free version isn't available.
i'd prefer a compile-time check as well, but std::atomic::is_lock_free is a run-time check ...
Hopefully, the atomic guys will take notice.
well, the standard allows implementations, where not all instances of std::atomic are lock-free. e.g. the lock-free property may depend on the object alignment tim -- tim@klingt.org http://tim.klingt.org There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs