Re: [boost] boost.lockfree update

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 
object alignment

tim

-- 
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