On Mon, Nov 11, 2002 at 02:31:28PM -0800, Perez-Gonzalez, Inaky wrote:
> > As long as the person attempting to manipulate the FUTEX word succeeds
> > (i.e. 0 -> 1, or 0 -> -1, or whatever), futex_wait() need not
> > be issued. futex_wake() only pins the page for a brief period of time.
> Define brief - remember that if the futex is locked, the page is already
> pinned, futex_wake() is just making sure it is there while it uses it - and
> again, as you said before, this is completely application specific; the
> kernel cannot count on any specific behaviour on the user side.
I am defining "brief" as the length of time that futex_wake() takes to
pin and unpin the page, which I hope is quite short as the internal
futex locks are also held during this time.
I might be doing something wrong -- but it seems to me that using inc,
dec, xchg or cmpxchg (depending on the object being implemented) is
all that is necessary for IA-32. futex_wait() should only be executed
by threads which decides that they need to wait, which on an
application with a well designed thread architecture, should not occur
frequently. I would find any application that needed to actively wait
on 4000 futex objects to be either incorrectly designed, or under
enough load that I think an investment in a few more CPU's would be
worthwhile... :-)
> > same cache line. Also, if the memory word is used to synchronize
> > access to a smaller data structure (<128 bytes), it is actually
> > optimal to include the memory word used to synchronize access to the
> > data, and the data itself, in the same cache line.
> Sure, this makes full sense; if you are using the futexes straight off from
> the kernel for synchronization; however, when used by something like NGPT's
> mutex system, the story changes, because you cannot assume anything, you
> have to be generic - and there is my bias.
> Lucky you that don't need to worry about that :)
In this case it isn't luck -- although I am certain that NGPT, and the
other recent projects to improve the speed of threads and thread
synchronization on Linux are doing very well, I have been dabbing with
purposefully avoiding 'pthreads-like' libraries for synchronization
primitives. Originally my goal was to reduce the overhead of a
MUTEX-like object and a RWLOCK-like object to be a single word. The
increased efficiency, and reduced storage requirement for these
storage primitives would allow me to use them at more granular levels,
which reduces the potential for contention.
At some point, the need to be absolutely general and portable gets in
the way of being efficient. You seem to be trying to accomplish all
three goals (NGPT), a task that I can appreciate, but one that I
cannot envy... :-)
mark
-- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, CanadaOne ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:23 EST