[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] kern: simple futex for gnumach (version 4)
|
From: |
Marin Ramesa |
|
Subject: |
Re: [PATCH] kern: simple futex for gnumach (version 4) |
|
Date: |
Tue, 24 Dec 2013 17:38:59 +0100 |
On 12/24/2013 05:20:41 PM, Richard Braun wrote:
On Tue, Dec 24, 2013 at 04:55:47PM +0100, Marin Ramesa wrote:
> I use a recursive futex_wake(). It first scans all the futexes if
> they are on the same offset and if they share the same vm_object.
> If they do, recursion is used to wake a number of threads in those
> futexes. The number of threads awakened is constant troughout the
> same offsets and in the same objects. In this way synchronization
> is possible. I don't do anything in futex_wait().
Right. Well, consider how small stacks usually are in a kernel, and
you should understand why anything recursive (except if bounded) is
unacceptable.
OK, thanks. I will reconsider and rewrite that code.
Then, why a scan through vm_objects ? Why not directly find the one
futex associated with a (map, address) and wake all threads waiting
on it ?
Yes, I could do it that way.
Also, why pass a number of threads to wake ? Why not simply choose
between one or all ?
I have read in "Futexes are tricky" that futex() is used with INT_MAX
argument. I want to keep that usage. So, if a number of threads to
wake is greater than number of threads in a futex I wake all.