tokio-sync: Acquire n permits from a semaphore

[jean-airoldie]

Currently the 0.2.0-alpha.4 Semaphore & Permit API of tokio-sync only allows one to acquire permits one at a time (as far as i can tell). Wouldn't the Semaphore API be more usefull is one could acquire an arbitrary number of permits at a time?

For instance Permit::poll_acquire_n would take an extra arg use to decide how much permits to acquire. And an extra check would be added to make sure the requested number of permits does not exceed the semaphore's total capacity.

My specific use case would be a async channel that blocks based on the combined len of the message it contains.

[carllerche]

👍 It probably would be nice to be able to acquire an arbitrary number of permits. I am unsure about how easy / hard it would be to add that though! If anyone wants to take a stab, I can try to take a look at strategy.

[jean-airoldie]

I took a quick look and I think it shouldn't be that hard. I'll take a stab at it once I'll need it, hopefully this week.

[jean-airoldie]

Alright I took a better look and it would be incompatible with the current semaphore design since it assumes that it only needs to wakeup a waiter if the permit count is zero. This is because, when the permit count is zero, then the SemState becomes a pointer to a waker. However, it would be possible that a thread tries to acquire more permits that are currently available while the number of available permits is non-zero.

[jean-airoldie]

What if the SemState used an index to a vec of WaiterNode instead of a pointer? The SemState could be a combination of the permit count, the index to the next waker and the flags, all contained in a u64. Something like 32bits for the permit count, 29bits for the index to the next waker (could be smaller) and 3bits for the flags would work.

[jean-airoldie]

This would limit the max amount of queued wakers, but I don't think thats much of a problem.

[jean-airoldie]

futures_intrusive has an implementation for such a semaphore.

[carllerche]

I’ll leave the issue open as I think the API would be useful and I would appreciate a contribution.

[FSMaxB]

I implemented something like this for limiting the amount of bytes that could be allocated for a certain purpose. My implementation definitely wouldn't be a general purpose solution, but I want to add my use case here.

I implemented this using a Mutex<Vec<Task>>. Adding tasks at the end if there weren't enough free permits and waking them starting from the front, skipping tasks that want too many and waking them until the limit is reached. This isn't applicable for every application though because of the lock and because depending on the workload some tasks might wait forever and never be notified.

[kornelski]

The low-level API for Semaphore has already implemented this feature. It would be great to expose this.

In my case I want to have a soft limit on amount of memory used in my server, so having permits equal to reserved memory and acquire_n(approx_memory_needed) would solve my problem.

[tuxzz]

Maybe we should also implement release_n and forget_n?
For example, we want to acquire all resource needed before execution to prevent deadlock or something, but when a subset of task finished, we want release it as soon as possible so that other tasks can reuse it.

[carllerche]

At this point, the issue should be fairly easy. Semaphore's internal implementation supports batch ops. It is just a question of exposing and documenting an API that uses the internal batch API.

Maybe something like: Semaphore::acquire_many(n).

[dcarrier]

I will give this a try.