RE: Pollable Semaphores

[Robert White]

The other obvious problem is that if there are contenders on the semaphore, the
semaphore may well not remain acquirable between the return from select and the call
to actually acquire the semaphore.

What I'd think you need is a "device" that you open, then attach a semaphore to (with
an ioctl()?), then you would write increment/decrement actions to the device file
descriptor and it would reply with the results.

By making the write and read actions be "normal" and "atomic" you end up with normal
produce/consume file operations and so normal interaction with poll/select.

I would imagine [off the top of my head] that each device node would have to have
some kind of tasklet-like (but blockable) context that could wait for the semaphore
in a non-blocking way.  (Actually I'd imagine a reverse hook in the semaphore itself
that would contain a linked-list of inactive tasklet references which would each be
activated on a suitable semaphore operation (increment).

The short version is that the "available" state must be atomic with the actual
decrement operation or you will probably end up blocking in the decrement after the
select() anyway.  Once you factor that in, all sorts of more-classic models suggest
themselves.

Rob White,
Casabyte, Inc.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/