Attendees
---------
Sven Dietrich - MontaVista
John Cherry - OSDL
Trent Shue - Bull
David Egolf - Bull
Joe Korty - Concurrent
John Cooper - Timesys
Ashish Karkare - Timesys


Sven - brief history of the conundrum

With RT and FUSYN, two PI mechanism would need to co-exist.
Independent wait queues would exist and cross referencing would
need to happen.  A cross-referencing implementation would 
probably be needed to manage the priorities in the two queues.

Additional, similar code redundancies would occur in the task-
exit management code.


Bull
- Working on a processor emulator
- Using current FUTEX
- Needed synchronization between processes


Robustness

The basic premise for user robustness is partially rooted 
in the requirements of high-availability systems, where 
failures on the task level must not require a system
reset. 


All complex code has bugs (obviously), and a robust user mutex
is the vehicle required for HA systems.

Robustness and priority inversion
- Robustness must be switchable or configurable.  Per mutex?
- PI needs to be globally enabled.
- Discussed the separation of robustness and PI.  Robustness
  is mainly HA and PI is mainly realtime performance.
- PI doesn't hurt any application.  When it is needed, it is
  needed regardless of cost.  There should be no performance
  hit in the uncontested cases.

Timesys has a mutex implementation that was used in the 2.4 timeframe,
but there was no interest in the kernel community.


Regarding System Calls

The Futex system call interface is oversimplified, more like 
the ioctl interface. Futex is not appropriate or sufficient 
for implementation of robust mutexes. This needs backup.

FUSYN has been pretty strongly rejected by the glibc maintainers.  It
would be good to understand why, but there are things that could be
done. 

      * Get standarized hooks into the kernel first (stable kernel
        interfaces such as scheduler hooks).
      * Break FUSYN CVS code into a set of discrete patches
      * Demonstate that the interfaces are solaris-like interfaces that
          have been implemented in other unixes.
      * Once kernel hooks are accepted, glibc changes are more likely
        

Fusyn Evolutionary issues to be addressed

- errno recoverability from existing syscalls
- Compatibility with system semaphore
- Separate FYSUN capabilities into no-drag kernel patches, such that if
not configured, no overhead is incurred in kernel (for acceptability)


RT Kernel Mutex Issues that are addressed in the FUSYN project. These
could be offered to Ingo once modularized

- SMP scalability
- Priority queues
- Fuqueue implementation is race-free


High Level User Mutex Requirements (from FUSYN capabilities)

- Uncontested Mutex locking without kernel
- Implementation of atomic access to userspace
- get_user race condition with page fault ?
- glibc changes (using pid) ?
- Robustness for check lock 
- Availability of per-mutex PI global switch
- Posix priority inheritance.


Other next steps
- Write a spec?  How to move to convergence rather than co-existence.
- Quantify RT overhead.  Could leverage some of the work that Inaky
  has done.
- Determine Ingos plans.  Probably the best way to do this is through
  code.
- Determine the best way to enable/configure RT.
- Detail and quantify the shortcomings of the futex interface.
- Topic at kernel summit?? 





--===============39779016561671576==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

_______________________________________________
robustmutexes mailing list
robustmutexes@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/robustmutexes

--===============39779016561671576==--