wakeup idea...

[Attilio Rao]

2006/3/6, dima <_pppp at mail.ru>:
> Sorry my ignorance. Gleb Smirnoff pointed that out privately already. I
looked at the code
> and it seems very much like OpenSolaris implementation to me. You can't
propagate
> priority properly if you don't hold all the current lock holders
somewhere. I tried to
> implement it as an array in my effort. As Attilio Rao mentioned, this
allows only fixed
> amount of concurrent readers at the time (which is not quite right, but
can be implemented
> as a per-lock sysctl tuneable). I chose an array to prevent introducing
one more mutex to
> the SX lock on the "short path". The code might look as the following:

You can't use a tunable sysctl if you plan to use a static array beacause
you work a compile-time and a malloc'ing stub is too much inefficient.
There's another problem too: dimensions.
If  you choice too much owners you will have something like (sorry, I've not
seen the code yet):

static struct thread *owners[NOWNERS];

On x86 sizeof(struct thread *) == 4 so owners table dimension is NOWNERS * 4
which is not so good.
Tracking owners is the biggest problem of this issue.

> This code is buggy, though. The array consisted of u_int32_t values first,
but it is hard to
> handle the recursive case this way. Introducing a structure makes it
impossible to handle
> the array atomically. I'm still stuck at this point and some other issues
(removing the locks
> on thread_exit is the largest one among them).

Handle recursion is simple if you get owners list per-turnstile or
per-your-primitive.
The main problem at this point is tracking owner.
If you do in a static way (as you do now) you are limited by number of items
and dimensions
if you do in a dynamic way (using a TAILQ) you are limited in performance.

Greetings,
Attilio

--
Peace can only be achieved by understanding - A. Einstein


--
Peace can only be achieved by understanding - A. Einstein