[pjsip] pj_thread_sleep(0) problem in linux platform issue

Simon Chen simonmychen at seed.net.tw
Thu May 22 00:07:15 EDT 2008


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 at pjsip.org>
To: "pjsip list" <pjsip at lists.pjsip.org>
Sent: Wednesday, May 21, 2008 6:59 PM
Subject: Re: [pjsip] 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
> 






More information about the pjsip mailing list