From: Michael Dickey (mike_at_[hidden])
Date: 2008-04-18 12:40:23
I for one would LOVE to see support in Boost for lock-free data
structures. I imagine that if these were more readily available, a
lot of C++ programmers would want to use them.
I took a (brief) look at the TSTL code (from /. on Freshmeat), and it
does not appear to be lock-free. Rather, it looks like a collection
of primitives for thread-safe programming (which overlaps the
Boost.Thread functionality) combined with some thread-safe data
structures that use these primitives.
Tim seems to have a great lock-free FIFO implementation, although I
see that it uses a GPL license rather than Boost. Any chance we could
convince you to change the license, Tim? (nudge, nudge, wink, wink) =)
I'd like to help make such a library part of Boost, but the more I
learn about lock-free coding, the more I discover that I have yet to
I think that for now the most I can offer is enthusiastic
On Apr 18, 2008, at 8:50 AM, <Lance.Diduck_at_[hidden]> wrote:
> If the CAS is prefixed with 'lock' (intel) then this emits a two way
> barrier. Virtually all compiler built ins of CAS do this. In my
> implementation of queue I did not need barriers other than those
> used by the CAS.
> I am interested in developing some lock-free libs for boost, if other
> are willing to help. I have a working unbounded MS Queue (relies on
> at the moment, but I have ideas on how to just support Single CAS
> the node allocator could always align on 64 byte boundaries, leaving
> space for a counter with a reasonable range). I have a linearized
> smart_ptr (which makes STM much much easier in C++). I have a
> std::allocator --compatible lockfree allocator (reduced contention
> inside of container quite a bit) and of course a stack.
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Patrick Twohig
> Sent: Friday, April 18, 2008 11:32 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Nonlocking data structures.
> Another article talks about writing on the Xbox360, which is what I
> needed a queue for:
> On Fri, Apr 18, 2008 at 3:51 AM, Giovanni Piero Deretta
>> On Fri, Apr 18, 2008 at 3:09 AM, Cory Nelson <phrosty_at_[hidden]>
>>> On Thu, Apr 17, 2008 at 5:24 PM, Patrick Twohig <p-twohig_at_[hidden]>
>>>> Theoretically, the CAS should atomically compare and swap the
>> in one
>>>> clock cycle. However, with multiple cores/processors/hyper
>> threading where
>>>> multiple instructions are being executed simultaneously over
>>>> numbers of clock cycles. There can be writes pending while you
>> to read
>>>> from memory. As a result, when you go to read something another
>>>> will have written to but you read stale data. To combat this,
>> enforce a
>>>> memory barrier, which guarantees that all pending memory
>> transactions before
>>>> the barrier have completed before moving on with the program.
>>>> some architectures (like x86) allow for unaligned access of
>> When an
>>>> unaligned value is accessed, it sets an exception then it
>>>> single read/write operation with multiple bus operations which
>> wreaks havoc
>>>> on any compare/swap operations.
>>> They don't happen in a single cycle, I don't think there is
>>> anything specifying that they should. Barriers aren't needed on
>>> x86 or x64, other than compile-time only ones to make sure the
>>> compiler doesn't reorder something.
>> Well, you actually need StoreLoad memory barriers on x86. All other
>> barriers are always implicit (unless you use non temporal SSE
>> StoreLoad is also implicit if you use locked operations, otherwise
>> need an explicit mfence.
>> See, for example, http://g.oswego.edu/dl/jmm/cookbook.html
>> Unsubscribe & other changes:
> Unsubscribe & other changes:
> Visit our website at http://www.ubs.com
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> E-mails are not encrypted and cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message which arise as a result of e-mail
> If verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities
> or related financial instruments.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk