[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Layering of the lll_[un]lock() and friends interfaces



Hi All

During our intent to modify NPTL to use the rtfutex interface we are
developing (http://sost.net/pub/linux/), we have stomped over a "problem".

As the lll_*() interface is set up, it takes directly a pointer (or
reference)
to the actual low level lock count. This way, from inside the lll_*()
macros/
functions, there is no way to access other data of the mutex.

The main interest we have is to be able to access flags in the mutex
structure that can tell us how the mutex has to behave (regarding stuff
like priority inheritance, protection, use or not use the real-time
interface,
...). Currently that is impossible.

So I would like to propose to move the lll_() interface to take pointers/
references to the whole mutex and then it would extract the interesting 
part/s.

This way, instead of calling (eg) in pthread_mutex_lock():

lll_mutex_lock (mutex->__data.__lock);

we'd call:

lll_mutex_lock (mutex);

And lll_mutex_lock() would change to be:

#define lll_mutex_lock(mutex) \
  (void) ({ int ignore1, ignore2;
\
	    __asm __volatile (LOCK_INSTR "xaddl %0, %2\n\t"		\
			      "testl %0, %0\n\t"
\
			      "jne 1f\n\t"
\
			      ".subsection 1\n"
\
			      "1:\tleal %2, %%ecx\n\t"			\
			      "call __lll_mutex_lock_wait\n\t"		\
			      "jmp 2f\n\t"
\
			      ".previous\n"
\
			      "2:"
\
			      : "=a" (ignore1), "=&c" (ignore2),        \
                          "=m" (mutex->__data.__lock)             \
			      : "0" (1), "2" (mutex->__data.__lock)	\
			      : "memory"); })


So, for the rt implementation, we can pack everything under the hood
of lll_mutex_lock() and not disturb at all any of the main .c files.
(this is specially true in the rt version of unlock, where we have to
deal with dead-owner conditions and stuff like that).

We'd be willing to take on the work to do all this - no functionality
is changed and it should be completely transparent to the end user.

Opinions?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]