Bug 2989

Summary:	Priority Inversion Problem?
Product:	TAO	Reporter:	Abdul Sowayan <abdullah.sowayan>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	NEW ---
Severity:	normal
Priority:	P3
Version:	1.5.9
Hardware:	All
OS:	All
Bug Depends on:	2990
Bug Blocks:

Description Abdul Sowayan 2007-07-16 13:54:49 CDT

Hi Folks,

I've been thinking about this for quite a while now, and talked to Johnny about it at OMG Workshop last week. The question at hand is, is there a potential for priority inversion within TAO? All of the TAO code base uses TAO_SYNCH_MUTEX, which is defined as ACE_SYNCH_MUTEX, which is defined as ACE_Thread_Mutex without the optional attributes to turn on priority inheritance or priority ceiling protocol.

CORBA RT-Mutexes are also a problem. I looked at the implementation and it uses TAO_SYNCH_MUTEX, which is defined as ACE_SYNCH_MUTEX, which is (you get the point). The below quote is from the holy RT CORBA spec (page 1-9) which says that a mutex MUST imploy some form of priority inheritance/ceiling protocol. This may be a non-conformance point in TAO to RT-CORBA spec.

"1.5.8 Real-time CORBA Mutexes and Priority Inheritance

The Mutex interface provides the mechanism for coordinating contention for system

resources. Real-time CORBA specifies an RTCORBA::Mutex locality constrained interface, so that applications can use the same mutex implementation as the ORB.

A conforming Real-time CORBA implementation must provide an implementation of Mutex that implements some form of priority inheritance protocol. This may include, but is not limited to, simple priority inheritance or a form of priority ceiling protocol. The mutexes that Real-time CORBA makes available to the application must have the same priority inheritance properties as those used by the ORB to protect resources. This allows a consistent priority inheritance scheme to be delivered across the whole system."

Thanks,
Abdul

Comment 1 Douglas C. Schmidt 2007-07-16 14:05:40 CDT

Hi Abdul, I think the easiest way to handle this would be to define an ACE_Priority_Inheritance_Thread_Mutex class and/or an ACE_Priority_Ceiling_Thread_Mutex class with the appropriate settings to get the desired results.  We could then simply define TAO_SYNCH_MUTEX to whatever users desired.  Please let me know if that makes sense.  Thanks, Doug

Comment 2 Abdul Sowayan 2007-07-16 14:20:21 CDT

Hi Doug,

Yes, that makes sense. The question is, for RT-based applications might not want to have an embrassing failure due to priority inversion such as the NASA's infamous Mars Pathfinder Mission.

The question goes beyond TAO. Does it make sense under RT-OSes to have ACE_SYNCH_MUTEX and TAO_SYNCH_MUTEX utilize something like ACE_Priority_Inheritance_Thread_Mutex by default out of the box (that might have a performance implication), and if the user doesn't want that they can change/configure ACE_SYNCH_MUTEX and TAO_SYNCH_MUTEX to ACE_Thread_Mutex (as we have it today).

Thanks,
Abdul

Comment 3 Johnny Willemsen 2007-07-17 05:25:32 CDT

changed severity

Comment 4 Johnny Willemsen 2008-03-20 16:05:57 CDT

I think we shouldn't change ACE_SYNC_MUTEX and TAO_SYNC_MUTEX but add a new define for the type that has priority inheritance protocol. This can then be used for the CORBA RTMutexes and by users, but using a priority inheritance protocol everywhere will probably do more harm then it solves.