Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Oleg Grunin (oleg00_at_[hidden])
Date: 2010-08-23 23:17:31

Thanks for the reply.

> sry for the delay, the mail got lost in my inbox ...
> 
>> 2. With VC++ on Windows both 32 and 64 bit, fifo reverts to using
>> spinlocks even though there's a 64 bit equivalent of interlocked
>> intrinsics in 64bit builds. Intel's implementation, I believe, supports
>> lockfree atomic<long long> even on 32 bit systems so this should be
>> possible.
> 
> 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.

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

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

>> All this said, I have to say that the fifo performance in our
>> environment (64 bit linux with 8 xeon processors, gcc 4.5) was quite
>> good. Comparable with tbb::concurrent_queue and way better than all the
>> other options we tried.
> 
> good to hear. tbb::concurrent_queue is a blocking algorithm (iirc they are 
> using spinlocks), while boost::lockfree::fifo is lockfree. so they have 
> somewhat different performance characteristics.
> the concurrent_queue may have acquire the spinlock and the os decides to 
> suspend the thread. this may be rare, but it is not impossible. the 
> lockfree::fifo doesn't have this issue ...
> 

I may be confused, but doesn't fifo have to spin (for(;;;)) also? Or do 
you mean that the tbb spin will call yield() after a certain number of 
tries?