Click here to Skip to main content
14,700,124 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I am trying to implement a state machine as a part of a class called" Source Transaction". Evey-time I receive a request in the main thread, it generates an instance of this class and the state machine starts executing until it reaches a state where it has to wait for a response in the main thread in the "event_handler". To solve this issue, I am implementing a conditional variable using boost libraries as following:

Source Transaction Class

boost::mutex mut;
	boost::condition_variable cond;


		boost::unique_lock<boost::mutex> lock(mut);
		while (!response_received)

		response_received = false;
		goto success_state;

And in the main file I have the following:

Main Class

Event_Handler function:
// Find the source transaction which corresponds to this Indication
src_transaction_ptr t;
tpool->find(msg.source(), mobile_id.to_string(), t);
    boost::lock_guard<boost::mutex> lock(t->mut);
    t->response_received = true;
// Dome some stuff

My problem is, every-time I execute the code, the state machine gets trapped in the "wait_ho_complete_indication_state" and it doesn't leave that state ,and additional to that the event_handler doesn't report that it has received any event. Like the main is being hanged.

So my question is there any problem in the implementation of the conditional variable?

Thanks a lot.
David Serrano Martínez 15-Mar-14 8:47am
Your implementation seems the canonical one, as described in:
The only difference is that you get out of scope with a goto jump. Does it anything to do with your unique_lock correctly going out of scope? I really do not know. Perhaps you will have to try some little alternatives in order to figure out what it is going on.
Mr.HA-AS 15-Mar-14 9:29am
Hi, I am following exactly the Boost documentation. I even tried to implement it without the goto jump. But I still get the same problem.
What other alternatives do you suggest? Also if you want more information, please check
David Serrano Martínez 15-Mar-14 14:19pm
It is quite difficult to find an answer with only fragments of code. Maybe the problem lies in the notification part. Perhaps notify_one is never reached. I suppose "tpool->find(msg.source(), mobile_id.to_string(), t);" invokes some t methods. Are you sure after those invocations the mutex in t is properly released?

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900