On Thu, May 22, 2008 at 5:07 AM, Simon Chen <simonmychen at seed.net.tw> wrote: > Hi! Benny, > > Sorry! I forgot describe my application firstly. > I use pjlib to implement a proprietary TCP serve-client application for > cross-platform issue. I got a problem when I use mutex lock and unlock to > protect the channel object. Two thread(A, B) will access the channel object > at the same time. Before channel object is accessed, lock the mutex and > unlock it after finished access. Thread A always loops to access the channel > object. Thread B sometimes access the it. In windows platform, it can work > perfectly. But in linux platform, Thread B can't access the channel object. > I add the pj_thread_sleep(0) between mutex unlock and lock to force task > switch. Then Thread B can sccess it. But this will cause the Thread A to > sleep 10 ms every loop in linux platform (in windows, pj_thread_sleep(0) > just forces task switch and don't sleep) This will cause my application > performance bad. > I have a feeling that something is not right there (I mean, one thread running on a busy loop doesn't sound like very efficient), but I don't want to criticize that. I'm just glad to hear that the problem is not in pjsip code. ;-) > I agree your statement "considering that application may create threads > with different priorities and also the process itself may be set to > particular scheduling policy, it may not achieve what we want", but I think > pj_thread_sleep(0) should be just forced to task switch. If wanna avoid the > different thread priorities or scheduling situation, using > pj_thread_sleep(n) may be more suitable. So I advance my suggestion. Is it > reasonable? Hope to hear your advice. Thanks! > Hmm.. actually from this: http://skyos.org/bugs/view.php?id=1972, it looks like usleep(0) and nanosleep(0) behaves differently than sleep(0), and it may be that sleep(0) will fit with what you want. What if you replace sched_yield() to sleep(0) for pj_thread_sleep(0) case in your patch? Does it work as expected? If so, then your patch will be more acceptable and we can defer sched_yield() discussion to another day. :) Cheers Benny
