Boost logo

Threads-Devel :

Subject: [Threads-devel] fixed size multiple producer multiple consumer queue full check
From: Neeraj Rai (rneeraj.rai_at_[hidden])
Date: 2016-06-30 20:09:48


Hi,

I don't have much experience with the lockfree code and have a very newbie
question about the use of relaxed memory load.
Would appreciate if someone more knowledgeable responds.

when do_push is called, I see relaxed load for node.next.

do_push synchronise uses pool.construct
#ifndef BOOST_DOXYGEN_INVOKED
    template <bool Bounded>
    bool do_push(T const & t)
    {
        node * n = pool.template construct<true, Bounded>(t,
pool.null_handle());
        handle_type node_handle = pool.get_handle(n);
if (n == NULL)
            return false; // can this return spurious false

pool.construct uses relaxed check

struct BOOST_LOCKFREE_CACHELINE_ALIGNMENT node
    {
        typedef typename detail::select_tagged_handle<node,
node_based>::tagged_handle_type tagged_node_handle;
        typedef typename detail::select_tagged_handle<node,
node_based>::handle_type handle_type;

        node(T const & v, handle_type null_handle):
            data(v)//, next(tagged_node_handle(0, 0))
        {
            /* increment tag to avoid ABA problem */*
tagged_node_handle old_next = next.load(memory_order_**relaxed);
* tagged_node_handle new_next (null_handle, old_next.get_next_tag());
            next.store(new_next, memory_order_release);
        }

is it possible that pool has been added to but not visible in current
thread and we get spurious pool full check

will this cause a race if other threads have added to the freelist and it
is not visible to current thread?

Is there a discussion on thread safety of operations in the queue and
freelist code?

I am specifically interested in fixed size queue.
With fixed size, the caller would have to check for failure so a race may
not cause a big issue, but I just need to understand if that is an
assumption that user is looping.

thanks
Neeraj



Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk