On Saturday 06 April 2002 04:48 am, Rusty Russell wrote: > In message <20020404162751.B0A253FE06@smtp.linux.ibm.com> you write: Enclosed is an "asynchronous" extension to futexes. This mechanism is required to implement global locks in the presence of an M:N threading package. Here "N" denotes a set of kernel threads, that serve as virtual processors on which the M user threads can be dispatched by the user level thread manager/scheduler. Under no circumstances can one block the kernel threads through the futex interface. Instead, I want to indicate to the futex-subsystem, that I want a notification for a particular futex, when its woken up. Working with some M:N threading folks we came up with the following design implemented in the attached patch to Rusty's previously posted futex generalization patch. I can also provide a integrated patch over 2.5.7 vanilla. The futex_q structure is extended to hold a , the of the futex and a signal with which to notify a caller. We now provide a FUTEX_AWAIT call which attaches a futex_q object to the wait queue, similar the FUTEX_WAIT. Differences are as follows. (a) futex_q must be dynamically allocated in the AWAIT case, instead of on the stack. We use the tgid to identify vs. == 0. (b) there will be no blocking in the kernel and hence we don't release the page upon return from this AWAIT call. (c) Upon wakeup, if the futex_q is an async wait (tgid != 0) we move it to a global notification queue and signal the with the specified signal. We release the page (put_page) at this point. If the doesn't exist (e.g. died), we delete futex_q and signal the next. (d) A FUTEX_AWAKERS call is provided to the application to retrieve waiting notifications, typically called within the signal handler. We need a cleanup mechanism for the notification queue, when a process dies prematurely before it had a chance to get their items out of the queue. For this I introduced _exit_futex(task) to be called from do_exit(). It simply wakes the notifcation queue and deletes everything that is associated with its pid. Right now that is done for each exiting task. In general one might want to think about a flag indicating whether this callback is necessary. For easier reading I also attach the futex.c program. Comments. -- -- Hubertus Franke (frankeh@watson.ibm.com)