On Thu, Jun 5, 2008 at 9:26 AM, Simon Chen <simonmychen at seed.net.tw> wrote: > Dear Benny, > > I have tried the sleep(0) solution. Task-switch will not occure when > the sleep(0) is called. Is there any other suggestion? > Just for reference, which linux kernel version is that? IMO, you shouldn't rely on pj_thread_sleep(0) to switch thread, since as you experience, it's not portable across platforms. Use explicit sched_yield() for that and Sleep(0) on Windows. Of course the ideal solution is to avoid this altogether by refactoring the application. > Any issue is about the bad TCP throughput. At Linux platform, > ioqueue_select performance is really not good. The TCP throughput is half > than using blocking socket directly. I have replaced ioqueue_select by > ioqueue_epoll.c. Its performance is good. But I don't know how to configure > makefile corrrectly for linux to use the ioqueue_epoll.c. Now, I use a > stupid method that modify directly the ioqueue_epoll.c filename to > ioqueue_select.c. Can you tell me how to configure it? Thanks! > You can modify this line in build.mak: export LINUX_POLL := select to export LINUX_POLL := epoll Mind you ioqueue_epoll has not been tested very extensively. Cheers Benny > Simon > > > ----- Original Message ----- > From: "Benny Prijono" <bennylp@xxxxxxxxx> > To: "pjsip list" <pjsip at lists.pjsip.org> > Sent: Thursday, May 22, 2008 5:50 PM > Subject: Re: pj_thread_sleep(0) problem in linux platform issue > > >> 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 >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
