Re: GSoC ticket #1069 (thread scheduler) application
Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> Thu, 12 Apr 2007 01:57:56 +0200
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2007-04-11 at 01:40:50 [+0200], André Braga <[email protected]> wrote: > On 4/10/07, Axel Dörfler <[email protected]> wrote: [...] > > You never need to search for them; whenever a blocked thread gets > > ready, the semaphore code will actively put this thread into the run > > queue; you don't have to care, you just have to write the code that > > actually puts it in there. > > Holy cow. That's embarassingly easier than what I had imagined. Still, > I can see how THIS operation is currently implemented O(n) ***where n > is the number of threads waiting on a given semaphore***. And, that, > too, is something I believe I can turn into O(1). Please note that: (1) There are usually not that many threads waiting for a single semaphore anyway. (2) The most likely semaphore release operation is with count 1, i.e. only the frontmost thread in the semaphore's queue will be woken up. (3) Even in cases were all waiting threads are woken up (e.g. delete_sem()) some info for each one needs to be updated, so the operation is "O(n)" anyway. CU, Ingo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV