Opened 11 years ago

Closed 11 years ago

#5840 closed Bugs (invalid)

thread.cpp: race condition in thread_proxy's thread state

Reported by: noloader@… Owned by: viboes
Milestone: To Be Determined Component: thread
Version: Boost 1.47.0 Severity: Problem
Keywords: Cc: viboes

Description

Using BOOST_HAS_PTHREADS to clarify the code, but all paths appear to suffer.

extern "C" {
  static void* thread_proxy(void* param)
  {
    // try
    {
      thread_param* p = static_cast<thread_param*>(param);
      boost::function0<void> threadfunc = p->m_threadfunc;
      p->started();
      threadfunc();
    }
    ...
  }

p->started() is called *before* the actual thread function. started() will change state even if an exception occurs such that the thread is not actually started:

void started()
{
  boost::mutex::scoped_lock scoped_lock(m_mutex);
  m_started = true;
  m_condition.notify_one();
}

Change History (4)

comment:1 by Jeffrey Walton <noloader@…>, 11 years ago

Component: Nonethread
Owner: set to Anthony Williams

comment:2 by viboes, 11 years ago

Cc: viboes added
Owner: changed from Anthony Williams to viboes
Status: newassigned

notify_one doesn't throws. So the single function that could be throw after setting m_started is the unlock implied by the scoped_lock. You should admit that there are not too many situations on which can lock a mutex and immediately after we can not unlock it, isn't it. This will be catastrophic, our system will stay with a mutex locked :(

So in reality I don't think we can fall in the situation you described, or maybe I am missing something important.

comment:3 by viboes, 11 years ago

Type: BugsSupport Requests

Move so Support request until resolution clarified.

comment:4 by viboes, 11 years ago

Resolution: invalid
Status: assignedclosed
Type: Support RequestsBugs

It seems the described situation can not be occur.

Please, reopen it if you don't agree with the resolution.

Note: See TracTickets for help on using tickets.