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?
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!
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
>
