I'm writing code to control a camera and I'm using boost threads to repeatly get the camera image and write it to a gui among a few other things while everything else runs. It's written with wxWidgets and it has a menu with an option to open/close the link to the camera and when I close the camera my program freezes and if I try to stop the program at this point visual studio tells me that the program is deadlocked.

I've gotten quite a bit of code and I think these are the relevant parts. This is the function that the thread I mentioned runs.

void Camera::main_loop()
{
	while(true)
	{
		get_image16();
		if(live)
		{
			get_image8();
		}

		if(last_buffer != pxd_capturedBuffer(1))
		{
			last_buffer = pxd_capturedBuffer(1);
			frame_count++;
			if(frame_timer->Time() > 1000)
			{
				frame_timer->Start(); 
				parent->SetStatusText(wxString::Format(wxT("%i, %i"), frame_count, pxd_getGPIn(1, 0)));
				frame_count = 0;
			}
		}
		
		if(do_stop())
			break;
	}
	delete client_dc;
	delete image;
}

This is what I run when I close the camera

void Camera::close()
{
	if(!opened)
	{
		return;
	}
	opened = false;
	stop();
	thread->join();
	pxd_goUnLive(1);
	pxd_PIXCIclose();
	delete []display_data;
	delete image_data;
}

And these are the stop and do_stop functions that are used for stopping the thread. When I start the thread I set stopping to false

bool Camera::do_stop()
{
	boost::mutex::scoped_lock l(c_mutex);
	return stopping;
}

void Camera::stop()
{
	boost::mutex::scoped_lock l(c_mutex);
	stopping = false;
}

When debugging the program seems to get to the line in the close function, thread->join();, after that nothing happens, then I kind of start placing break points all over my program with no results. This code worked before, and I'm not sure what's breaking it now.

Do you know what line the main_loop code in the thread gets to?

Given it is flagged as a deadlock Im thinking this could potentially be a case where clicking 'close' caused your main thread to acquire a wxWidgets resource that your main_loop code needs to access before it reaches the stop condition.

Im not that familiar with the boost library's scoped locks but your usage of them fits what you would expect for the basic implementation of a scoped lock.

This article has been dead for over six months. Start a new discussion instead.