Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-08-31 06:52:15
>> 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
-- tim_at_[hidden] 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk