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
