Re: boost::mutex - are lock attempts queued?

Szabolcs Ferenczi wrote:
> The workaround is that you explain what you want to achieve and we can
> help you coming up with a thread compliant design for your problem.

I think Paavo came up with what I need to do.

I'm trying to access two different types of data with two different 
threads: master thread = GUI (wxWidgets) event handlers, child thread = 
continuous boost::thread network traffic handler.

The master thread shall be able to signal the child thread to terminate, 
that makes up one of the data types I need to access there: a keepalive 
flag for the thread (or boost::condition, in the future). The other type 
of data is GUI controls, upon which wxWidgets holds a lock (of its own 
type) while any event handler is running, and the child thread can only 
access these for reading or writing when no GUI event handler is active.

So a possible timeline goes like (* = child thread running, x = event 
handler):

x  disable child thread status control on GUI
x  change GUI status control to "stop child thread"
x  start child thread (button event handler)
x* end event handler
  * enable child thread status control on GUI
  * handle network traffic until user clicks a button to end child thread
  * ...
  * (user presses button "end child thread")
x* disable child thread status control on GUI
x* change GUI status control to "start child thread"
x* signal child thread to exit
x* send a predefined packet to get child thread out of listening mode
x* end event handler
  * end current network servicing loop
  * enable child thread status control on GUI
  * end child thread

All the time, the child thread will update status indicators on the GUI, 
which can only be accessed while no event handler is running.

Best Regards,

   Lars