This question goes out to you POSIX

[ImpactCorey]

This question goes out to you POSIX thread experts.

I have two threads set up, one for the GUI, one for a DAQ server. The DAQ server aquires the data and updates the visible GUI screen every 1/2 second (loop with a sleep in it) and calls my Controller::update_gui function. The GUI will switch the screen whenever certain radio buttons are pressed. The function for this is Controller::switch_gui.

I set up a mutex lock around the two functions so the insides won't be executed at the same time. i.e. the GUI should not be updated if the screen is changing. You can see it is not important for the gui to always update. It merely tries to lock the mutex but if it is unsuccessful just exits the function. The GUI change must always occur. I figured having condition waits are unnecessary. (I don't even know how I would implement them other than on the update_gui function but like I said, it isn't necessary to run every time it is called). The problem is, I get deadlocks.

Here is my code: Does anybody see anything wrong with it?

// update the gui_list
int Controller::update_gui( int iUpdateType )
{
if( pthread_mutex_trylock( &mutex ) != 0 )
return -1;

// loop through all dialogs in map and update each one
notify( iUpdateType );

pthread_mutex_unlock( &mutex );
return 0;
}


int Controller::switch_gui( int iOldID, int iNewID, ObserverDlg * dlg )
{
pthread_mutex_lock( &mutex );

// remove dialog at key "iOldID"
detach( iOldID );
// add dialog "dlg" at key "iNewID"
attach( iNewID, dlg );

pthread_mutex_unlock( &mutex );

return 0;
}

 

[PhilMumf]

1) Have you initialised you mutex varible correctly?
2) Are you sure you are using the same instance of the Mutex varible in both functions.
3) If your GUI does not have to update at exactly 30 second intervals, you could just

mutex_lock
update GUI
mutex_unlock
sleep(30); // lock may block so actual loop time > 30

This would eliminate any problems there might be with trylock (I don't use this myself).

4) For safety, I use a class which locks in the constructor and unlocks in the destructor. You might have missed an unlock somewhere else in your code.

class DoMutex
{
public:
DoMutex(pthread_mutex_t *aMutex)
{
mMutex = a Mutex;
pthread_mutex_lock(mMutex);
}
~DoMutex()
{
pthread_mutex_unlock(mMutex);
}
private:
pthread_mutex_t *mMutex
};

5) Are you sure you compiled with the -mt option (or equivalent on your compiler)? In solaris you have to do this.

6) It could be elsewhere in your code that something not mutexed is causing a problem (e.g. accessing a resource of some sort in both threads?)