Question

Question

eventfd() is a new system call available in Linux since 2.6.22. The call signature is

int eventfd(unsigned int initval, int flags);

I am making use of this call in constructing a new light saberLock class that’s usable in a polling loop.

The Python Lock object starts in an unblocked state. My use of eventfd requires then that the initial value be non-zero. If the value is internally a uint64_t,

The object contains an
unsigned 64-bit integer (uint64_t) counter that is maintained by the
kernel.

why is the initial value argument of type unsigned int?

Overt Detail

If I use non-zero values as the unlocked state of the Lock, releases are done by writing. Multiple releases without intervening acquires, are erroneous and need to fail. This requires that writing should fail when the event object contains a non-zero value. In its default mode, the event object will add values posted to it up to (uint64_t)0xfffffffffffffffe, before blocking write calls. To detect this situation I will do a nonblocking write that pushes the value over this maximum triggering this circumstance:

If the addition would cause the counter’s
value to exceed the maximum, then the write(2) either blocks
until a read(2) is performed on the file descriptor, or fails
with the error EAGAIN if the file descriptor has been made non‐
blocking.

Answer 1

If I understand you correctly, you want to have the state of this beast to alternate between 0 and UINT64_MAX-1?

The type of the initial value is probably just there for historical reasons. Once that such an interface is used it sticks and it is difficult to change it afterwards.

If you need the value to be initially UINT64_MAX-1 why not just call eventfd with a 0 argument and do a write with UINT64_MAX-1 immediately after, before you propagate the file descriptor to anybody else:

int ev = eventfd(0, 0);
write(ev, &(uint64_t const){ UINT64_MAX-1 }, sizeof(uint64_t));

(well you’ll add the error checking code, don’t you)