Re: condvar

On 2005-03-17 at 19:14:04 [+0100], Axel Dörfler wrote:
> 
> to be able to efficiently implement a condvar mechanism (and similar
> things), it would be great to atomically release one semaphore while
> aquiring another.

Not having thought much about condition variables yet, I suppose doing this 
atomically is necessary since the implementation would require to be able 
to switch the semaphores in both directions, right?

> Together with the new B_RELEASE_ALL flag, condvar could then be
> implemented very easily.
> 
> The functionality is very trivial to implement, that's why I've already
> done it - the question is on how we make it public.
> There are basically 3 possibilities:
> 1) keep it private for R1
> 2) (the messy version) add another flag to acquire_sem_etc() that
> reinterpretes the "count" parameter as semaphore to be released - this
> has the advantage that no new system call is added;

System calls are cheap, so this isn't a valid advantage.

> it's by no means
> backwards compatible, though (the app would run incorrectly on
> systems).
> 3) (the clean version) add a new pair of system calls: switch_sem() and
> switch_sem_etc() (other naming suggestions are welcome). Applications
> using these functions would not run on R5 or Zeta anymore.
> 
> For now, I did 3) here in my working copy, and I wanted to know what
> you think of it.

I don't really see anything that speaks for 2), so I fully agree to go with 
3). In principle this doesn't even collide with 1). So, why not introduce 
the functions, but keep them private (or document them being private).

CU, Ingo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click