Opened 11 years ago
Closed 11 years ago
#5840 closed Bugs (invalid)
thread.cpp: race condition in thread_proxy's thread state
| Reported by: | 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 , 11 years ago
| Component: | None → thread |
|---|---|
| Owner: | set to |
comment:2 by , 11 years ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:3 by , 11 years ago
| Type: | Bugs → Support Requests |
|---|
Move so Support request until resolution clarified.
comment:4 by , 11 years ago
| Resolution: | → invalid |
|---|---|
| Status: | assigned → closed |
| Type: | Support Requests → Bugs |
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.

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.