[Cbe-oss-dev] [PATCH 1/5] MARS: yield in workload queue wait busy loop

Kazunori Asayama asayama at sm.sony.co.jp
Wed Jul 16 01:22:01 EST 2008


Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Yuji Mano wrote:
>> @@ -194,9 +195,8 @@ int workload_queue_wait(struct mars_work
>>         MARS_CHECK_RET(queue->block[block].state[index] !=
>>                         MARS_WORKLOAD_STATE_NONE, MARS_ERROR_STATE);
>>  
>> -       while (*(volatile uint8_t *)&queue->block[block].state[index] !=
>> -               MARS_WORKLOAD_STATE_FINISHED) {
>> -       }
>> +       while (queue->block[block].state[index] != MARS_WORKLOAD_STATE_FINISHED)
>> +               sched_yield();
>>  
>>         return MARS_SUCCESS;
>>  }
> 
> I think you should try to avoid busy loops altogether. Doing sched_yield()
> here (or anywhere else) will not give you the right behaviour. When you are
> waiting for a value in memory to change, basing your waiting primitive on
> futex should give you the best performance.
> 
> If you don't want to write the futex code yourself, you can use a
> pthread_cond_t variable for waiting, but you can't currently use those
> from an SPU, unlike futexes, which you can access using the SPU syscall
> support in the kernel.

MARS assumes (near) realtime and/or interactive applications, so 
synchronization functions tend to be frequently called. Thus we'd like 
to avoid stopping an SPE(SPU syscall causes stop&signal) when 
synchronization objects are used. Instead, if the SPE stalls on 
synchronization, MARS implicitly switches to another runnable MARS task 
without stopping the SPE, so that the SPE's usage increases. In the 
other words, this behavior is one of major advantages of MARS.

This is the reason why we choosed memory based synchronization for MARS. 
    Do you have any suggestion?

-- 
(ASAYAMA Kazunori
   (asayama at sm.sony.co.jp))
t




More information about the cbe-oss-dev mailing list