Re: [Boost-Users] Re: Re: Newbie needs pointer to currently executing thread.

From: dick.bridges_at_[hidden]
Date: 2002-04-11 17:32:46

Thanks for the response.

Because this pattern involves a condition.wait() followed by select(), I
believe that only the leader should be able to set the predicate to
NO_CURRENT_LEADER.  Otherwise there is the [very unlikely] danger that a
spurious wake up on the condition could result a second thread attempting
to process the same handle/event before the first thread could deactivate
it.

Although I can wait until all the housekeeping for the select() has been
done before unguarding the condition and continue with processing the
event, that's a little more synchronous than I care for given that a simple
comparison against a thread id allows me to unguard the condition much
earlier.  Actually, for now, that's EXACTLY what I'm going to do.  Probably
good enough anyway.  ;)

Thanks again for the response and for the info on Bill Kempf's intent to
provide portable thread_id s.

                                                                                                                                        
                      "Moore, Dave"                                                                                                     
                      <dmoore_at_ashtontec         To:      "'Boost-Users_at_[hidden]'" <Boost-Users_at_[hidden]>                  
                      hgroup.com>               cc:                                                                                     
                                                Subject: [Boost-Users] Re: Re: Newbie needs pointer to currently executing thread.      
                      04/11/2002 12:48                                                                                                  
                      PM                                                                                                                
                      Please respond to                                                                                                 
                      Boost-Users                                                                                                       
                                                                                                                                        
                                                                                                                                        

<dick.bridges_at_[hidden]> wrote in message
news:OFAB9F41E0.6C6A5A14-ON88256B97.005045D8_at_tais.net...
>
> I'm implementing the Leader/Followers thread pool pattern - reference
> "Pattern-Oriented Software Architecture Volume 2" (Schmidt, et al).
>
> When a thread is released via notify_one(), it is [assumed to be] in the
> "leader" role and stores it's id.  A sanity check should be performed to
> verify that there is no other thread in the leader role (i.e.,
> current_leader is "none") before the thread stores it's id there.
>
> When one of the event sources is signaled and the leader is unblocked, it
> must, among other tasks, demote itself (i.e., set the current_leader
value
> to "none")
> and promote one of the followers by notify_one() before continuing to
> service the request.  Because of the potential for race conditions,
> (especially in the context of future program updates, modifications,
etc.)
> I should enforce the rule that only the leader can promote a follower.
> Something along the lines of:  current_leader == Thread::this().
>

I disagree (about the race condition).  Your condition variable is usually
used in conjunction with a mutex which protects your shared state's
invariants.

boost::mutex m;
boost::condition c;
Invariant:  leader != NONE

Pseudo-code for leader releasing

boost::mutex::scoped_lock l(m);    // lock mutex
if(TimeForANewLeader)
{
    leader=NONE;
    c.notify_one();        // Will signal one waiter.....

    // finish task - MUTEX IS STILL HELD!
    //
}

l.unlock();    // Only now will a waiter return from wait();

Pseudeo-code for follower waiting for signal:

boost::mutex::scoped_lock l(m);    // lock mutex

while(Not TimeForANewLeader)
{
    c.wait(m);    // Waiting automically releases AND reacquires
                        // the mutex
 }
// When we get here, we know we hold the mutex.
// Follower is responsible for "self-promotion"
leader=ME;

// Start my work as a leader.

An important note is that if we reach the while() statement and it IS time
for a new leader, then
we never wait, we already hold the mutex, and it is safe for us to promote
ourselves anyways!

Note that for the time being, you'll have to go outside of Boost.Threads
for
the leader=ME statement because thread objects aren't copyable so
leader=boost::thread(); doesn't work to get the current thread.  Bill Kempf
has indicated that some form of portable thread_id s are coming in a future
version.

Hope this helps...
Dave

>

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/