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 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!
Simon chen
----- Original Message -----
From: "Benny Prijono" <bennylp@xxxxxxxxx>
To: "pjsip list" <pjsip at lists.pjsip.org>
Sent: Wednesday, May 21, 2008 6:59 PM
Subject: Re: pj_thread_sleep(0) problem in linux platform issue
> On Wed, May 21, 2008 at 3:41 AM, Simon Chen <simonmychen at seed.net.tw>
> wrote:
>> Hello!
>>
>> pj_thread_sleep(0) is used for forced task switch sometimes. It can
>> work
>> find in windows platform. But in linux platform, pj_thread_sleep(0) will
>> sleep 1 tick. This will effect the performance of the thread. I modify
>> the
>> pj_thread_sleep in os_core_uinx.c. When msec equals 0, call
>> sched_yield().
>> It can work find in my test. How about this modification for the pjlib?
>> any
>> suggestion? Thanks!
>>
>
> Can you explain more about which particular pj_thread_sleep(0) that
> gives poor performance? I grep-ed the source for pj_thread_sleep(0)
> and I found three places where it's used, and all I think are for
> corner cases (like waiting for deadlock resolution) where I don't
> think pj_thread_sleep(1) and sched_yield() will make big difference in
> performance. But I could be wrong, hence it'll be great if you could
> explain more.
>
> The reservation that I have against sched_yield() is it seems that
> this syscall is less well specified (see [1]), so 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 (not that I know for sure what do we really want
> in the first place with sleep(0), but it's something like "let all
> other ready threads run then get back to me").
>
> Cheers
> Benny
>
> [1] http://lkml.org/lkml/2007/9/19/328
>
>
>
>> PJ_DEF(pj_status_t) pj_thread_sleep(unsigned msec)
>> {
>> /* TODO: should change this to something like PJ_OS_HAS_NANOSLEEP */
>> #if defined(PJ_RTEMS) && PJ_RTEMS!=0
>> enum { NANOSEC_PER_MSEC = 1000000 };
>> struct timespec req;
>>
>> PJ_CHECK_STACK();
>>
>> // modification start -----------
>> if( msec == 0 )
>> {
>> sched_yield();
>> return PJ_SUCCESS;
>> }
>> // modification end -----------
>> req.tv_sec = msec / 1000;
>> req.tv_nsec = (msec % 1000) * NANOSEC_PER_MSEC;
>>
>> if (nanosleep(&req, NULL) == 0)
>> return PJ_SUCCESS;
>>
>> return PJ_RETURN_OS_ERROR(pj_get_native_os_error());
>> #else
>> PJ_CHECK_STACK();
>>
>> // modification start -----------
>> if( msec == 0 )
>> {
>> sched_yield();
>> return PJ_SUCCESS;
>> }
>> // modification end -----------
>> pj_set_os_error(0);
>>
>> usleep(msec * 1000);
>>
>> return pj_get_os_error();
>> ;
>> #endif /* PJ_RTEMS */
>> }
>>
>>
>> Simonmy
>>
>>
>
> _______________________________________________
> 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
>
