[Xenomai] Mutex enhancement for Auto relaxed threads

* [Xenomai] Mutex enhancement for Auto relaxed threads
@ 2012-11-22 15:51 Makarand Pradhan
  2012-11-22 16:15 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 9+ messages in thread
From: Makarand Pradhan @ 2012-11-22 15:51 UTC (permalink / raw)
  To: xenomai@xenomai.org

Greetings,

I have a proposal for enhancing the process of locking a real-time mutex in auto-relaxed Xenomai threads. It will  save a lot of CPU cycles in some scenarios, and I would like to get your expert opinion about it (I have coded the enhancement for native skin and changes are attached to this email).

Xenomai mutex is designed in such a way that trapping to the kernel is not needed.This is a very efficient design which saves a great deal of CPU cycles.
However, there is an exception to this efficient behavior: if the Xenomai thread is an auto-relaxed thread (i.e. running with priority 0), locking a mutex always traps to the kernel because the current implementation handles auto-relaxing upon exiting the system call.

Look at this scenario:

A Xenomai thread
1) locks a mutex (which is an OUTER mutex in this scenario)
2) then loops multiple times through some operation that requires locking an unlocking some other mutex (INNER mutex)
3) unlocks the OUTER mutex

If the thread is a real-time thread, locking mutexes is done efficiently. If the thread is auto-relaxed though, both OUTER and INNER mutexes cause trapping to the kernel which is not really needed.
Please note that locking the OUTER mutex already moves the thread to the primary domain, so handling the INNER mutex could be done as if the thread was a real-time (non-auto-relaxed) thread.

Enhancements:
The mutex code was modified in such a way that priority 0 (auto-relaxed) thread will do a system call only once when grabbing and releasing the outtermost mutex. The inner mutexes will not jump into the kernel. This change would significantly save CPU cycles by using the user space fast mutexes when the thread is not relaxed after grabbing the outtermost mutex.

I would highly appreciate your comments.

Best Regards,
Makarand
Software Engineer
RuggedCom Inc.
www.ruggedcom.com
300 Applewood Crescent
Concord, Ontario, L4K 5C7
Tel:  (905)482-4523
Fax: (905)856-1995

-- 
___________________________________________________________________________
NOTICE OF CONFIDENTIALITY:
This e-mail and any attachments may contain confidential and privileged information.  If you are
not the intended recipient, please notify the sender immediately by return e-mail and delete this
e-mail and any copies.  Any dissemination or use of this information by a person other than the
intended recipient is unauthorized and may be illegal.
_____________________________________________________________________

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xenomai_changes
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121122/fc104aa6/attachment.ksh>

^ permalink raw reply	[flat|nested] 9+ messages in thread