Ingo Molnar wrote:
>
> * Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>
> > The futex man pages that have been around for years (certainly since
> > mid 2002) certainly don't document FUTEX_WAIT as token passing
> > operation, but as atomic operation:
> >
> > Say http://www.icewalkers.com/Linux/ManP
* Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> The futex man pages that have been around for years (certainly since
> mid 2002) certainly don't document FUTEX_WAIT as token passing
> operation, but as atomic operation:
>
> Say http://www.icewalkers.com/Linux/ManPages/futex-2.html
besides this doc
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> > [numerous instances of...]
> > + preempt_check_resched();
>
> Not required. The spin unlocks will do this.
Here is updated patch with those removed (all of them are preceeded
by spin_unlock) and out_unqueue label and following u
On Thu, Mar 17, 2005 at 03:20:31PM +, Jamie Lokier wrote:
> If you change futex_wait to be "atomic", and then have userspace locks
> which _depend_ on that atomicity, it becomes impossible to wait on
> multiple of those locks, or make poll-driven state machines which can
> wait on those locks.
Jakub Jelinek wrote:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0411.2/0953.html
>
> Your argument in November was that you don't want to slow down the
> kernel and that userland must be able to cope with the
> non-atomicity of futex syscall.
Those were two of them.
But my other main concer
On Thu, Nov 18, 2004 at 02:47:26PM -0500, Jakub Jelinek wrote:
> The scenario described in futex_wait-fix.patch IMHO can happen even
> if all calls to pthread_cond_signal are done with mutex held around it, i.e.
> A B X Y
> pthread_mutex_lock (&mtx);
> pthrea
6 matches
Mail list logo
