Date: Tue, 7 Mar 2006 09:49:24 +0100 From: "Attilio Rao" <asmrookie@gmail.com> To: freebsd-arch@freebsd.org Subject: Re: Re[2]: wakeup idea... Message-ID: <3bbf2fe10603070049r36407660y@mail.gmail.com> In-Reply-To: <3bbf2fe10603070044j745d5509n@mail.gmail.com> References: <200603061353.13756.jhb@freebsd.org> <E1FGOCp-000BEU-00._pppp-mail-ru@f52.mail.ru> <3bbf2fe10603070044j745d5509n@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/3/6, dima <_pppp@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 no= t seen the code yet): static struct thread *owners[NOWNERS]; On x86 sizeof(struct thread *) =3D=3D 4 so owners table dimension is NOWNER= S * 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 item= s 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10603070049r36407660y>