Question about synchronization object

Jan Kiszka jan.kiszka at siemens.com
Fri Dec 14 13:07:17 CET 2018


On 14.12.18 10:14, duanwujie wrote:
> Hi, Phi and Jan:
> 
> I have question about  synchronization object.Consider under condition.
> 
> *
> *
> 
> *Thread A*
> 
>      mutex_lock(lock)  //O1
> 
>      ...
> 
>      ...
> 
>      mutex_unlock(lock)//O2
> 
> *Thread B*
> 
>      mutex_lock(lock) //O3
> 
>      ....
> 
>      ....
> 
>      mutex_unlock(lock);
> 
> 
> O1:  become xnsynch's owner.
> 
> O3:  blocked to wait thread A unlock mutex.
> 
> O2:  this will call sc_cobalt_mutex_unlock syscall then transfer owner to thread B.
> 
>         But in the xnsynch_release's  "likely condition" seems that  
> transfer_ownership will  not be called. Therefore, how to resume thread B ?
> 
>        Is there something i misunderstood  for xnsynch_fast_release ?
> 
> 
> struct xnthread *xnsynch_release(struct xnsynch *synch,
>                   struct xnthread *thread)
> {
>     /* .................................. */
>      if (likely(xnsynch_fast_release(lockp, threadh)))//This condition
>          return NULL;

xnsynch_fast_release() is just a double-check - before going into the slow path 
with the leaving owner - if there is still a waiter for the lock. If there is 
(the fastlock word does *not* only contain the handler of the current owner, 
also has XNSYNCH_FLCLAIM set), we will branch into transfer_ownership.

BTW, to understand the real flow, you can try turning on the function graph 
tracer of the Linux kernel and catch the call graph of an interesting syscall. 
Or you use the gdb stub of QEMU[/KVM] running a Xenomai kernel for symbolic 
kernel debugging (stepping through the source code).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list