Need advice on std::queue syncronization using boost::mutex - maybe a bug in pthread?

Hello All!
I`d like to ask for your kind advice regarding boost::mutex behaviour.
I dont see what i`m doing wrong here. The issue is that at some point a
mutex used to syncronize access to std::queue becomes locked on it's own,
despite being explicitly unlocked before. I can repeat this more or less
consistently. I triple checked the logic behind code and it seems correct to
me.
Here is the code and some explanations (i build and test under windows):
Class itself:
#pragma once
#include <queue>
// simple std::queue based boost::mutex syncronized queue
template <typename T> class SyncedQueue : boost::noncopyable
{
private:
std::queue<T> queue;
// this is intended to be locked when queue is empty
boost::mutex emptyIndicator;
//this is intended to be locked when queue is being modified
boost::mutex accessGuard;
public:
SyncedQueue(const SyncedQueue<T> &)
{
//no copy constructor since we got mutexes
}
SyncedQueue()
{
// Queue is empty at start
emptyIndicator.lock();
}
bool push ( T object )
{
accessGuard.lock();
queue.push(object);
// if someone has been waiting for data to become available in queue
- let them go on
emptyIndicator.unlock();
accessGuard.unlock();
return true;
}
bool pop ( T& object )
{
// See if data is available, wait to aquire lock otherwise
emptyIndicator.lock();
// OK, somethings in the queue now, we can go on
accessGuard.lock();
object = queue.front();
queue.pop();
// If there is anything left in the queue - release emptyIndicator
to notify other poppers that they can go on
if (queue.size() > 0)
{
emptyIndicator.unlock();
}
accessGuard.unlock();
return true;
}
};
Here is the test Code:
#include "stdafx.h"
#include <string>
#include <iostream>
#include

AMDG Ilya Kalujny wrote:
I`d like to ask for your kind advice regarding boost::mutex behaviour.
I dont see what i`m doing wrong here. The issue is that at some point a mutex used to syncronize access to std::queue becomes locked on it's own, despite being explicitly unlocked before. I can repeat this more or less consistently. I triple checked the logic behind code and it seems correct to me.
The thread that unlocks a mutex must be the same one that locked it. You really ought to use a condition variable. In Christ. Steven Watanabe

Thank you kindly!
2008/12/12 Steven Watanabe
AMDG
Ilya Kalujny wrote:
I`d like to ask for your kind advice regarding boost::mutex behaviour.
I dont see what i`m doing wrong here. The issue is that at some point a mutex used to syncronize access to std::queue becomes locked on it's own, despite being explicitly unlocked before. I can repeat this more or less consistently. I triple checked the logic behind code and it seems correct to me.
The thread that unlocks a mutex must be the same one that locked it. You really ought to use a condition variable.
In Christ. Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Ilya Kalujny
-
Steven Watanabe