[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1154118676.19722.41.camel@localhost.localdomain>
Date: Fri, 28 Jul 2006 16:31:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Theodore Tso <tytso@....edu>, Neil Horman <nhorman@...driver.com>,
"H. Peter Anvin" <hpa@...or.com>,
Segher Boessenkool <segher@...nel.crashing.org>,
Dave Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org,
a.zummo@...ertech.it, jg@...edesktop.org
Subject: Re: A better interface, perhaps: a timed signal flag
On Fri, 2006-07-28 at 21:36 +0100, Alan Cox wrote:
> Ar Gwe, 2006-07-28 am 16:12 -0400, ysgrifennodd Steven Rostedt:
So what language does the above come from ;-) "Ar Gwe" "ysgrifennodd" ?
> > what the kernel does with wake_up. That way you can sleep till another
> > process/thread is done with what it was doing and wake up the other task
> > when done, without the use of signals. Or is there something that
> > already does this?
>
> futex and sys5 semaphore both do this. The latter is very portable but a
> bit less efficient.
semaphore is a bit awkward for this (I have implemented it for this type
of purpose and it really feels like a hack).
How can this be implemented with futex?? Let me make another scenario.
If you have a task sleeping and it needs to be woken when some other
task needs it (kind of like a kthread) but it doesn't know what task
will wake it. A futex is like a mutex where it has one owner, so you
can sleep till the owner awakes it, but you don't know who the owner is.
I really like the way the kernel has the wake_up_process function, and
it is vary handy to have for even user space. Right now the most common
way to do it is semaphores (yuck!) or signals. Both are very heavy and
I don't really see why a new interface can't be introduced. Yes, it
breaks portability, but it if becomes a standard, then others will port
to it (and maybe it will become a new POSIX standard :)
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists