Re: linux and pthread

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

On Wed, 2004-11-10 15:02:36 -0500, Simon Drouin <sdrouin@bic.mni.mcgill.ca>
wrote in message <419273DC.3050208@bic.mni.mcgill.ca>:
> Not sure it is the best place to post that. Tell me if you have any 
> other suggestion.

At least, it's appropriate to ask here.

> I'm running Mandrake 10 and developping a C/C++ program using multiple 
> threads. My program has a main thread that manages UI and a second 
> thread is in a loop that continuously grabs data from a serial port. The 
> communication between the 2 threads is controled by a mutex. The 
> grabbing thread holds the mutex for most of the time in its loop. My 

I guess here's the real problem.

> problem is that when the main thread tries to lock the mutex, it is 
> suspended forever,  like if the grabbing thread didn't release the mutex 
> lock for long enough for the main thread to lock it.

Why do you keep the lock locked? Most of the time, mutexes tend to be
unlocked nearly always and only get locked if (eg. for your example) the
serial thread got a byte and queues it in for the UI thread for
displaying/dispatching/whatnot.

Maybe the trick is to actually use a condition here: let the UI thread
(or a new one) just sleep on the condition. If you got a byte, lock a
mutex (if there are other placed that can access your global serial byte
buffer), queue it in, unlock and wake up the thread(s) sleeping in the
condition. Then, all of them (or only the UI thread) can re-display the
buffer state.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]