Add Stack
#4112
Add Stack
#4112
Conversation
BalmungSan
commented
Aug 3, 2024
•
BalmungSan
commented
- Interface
- Docs
- Tests
- Implementation
|
Queue, PQueue and Dequeue are split into Source/Sink interfaces to allow for Functor and Contravariant interfaces. This should probably have the same treatment? |
I thought about doing something like that, but TBH, not sure if it is really worth the effort. Personally, I think that if you want to hide part of the interface and add extra functionality like But, would love to hear what others think. |
BalmungSan
force-pushed
the
add-stack
branch
from
196822f to
c97e947
Compare
…ple pops with a pushN' test
BalmungSan
force-pushed
the
add-stack
branch
from
c97e947 to
0fb4739
Compare
| // But, if we didn't managed to invalidate it. | ||
| // Then, that means we managed to receive a pushed element. | ||
| // Thus, we have to push it again to avoid it getting lost. | ||
| waiter.get.flatMap(element => this.push(element)) |
There was a problem hiding this comment.
Couldn't this let elements slip under the top the stack if a push happens after the pop then before the push back? ie. stack of A,B,C:
- pop A but cancellation happens
- before push is called, another thread pushes D
- finalizer pushes A back
Now you'd have A,D,B,C, which should be impossible.
There was a problem hiding this comment.
Yes, concurrent pop cancellation and push can change the order of elements in the Stack, I don't think there is much we can do here tho, we would need to store more information and the implementation would be very complex.
Also, note that for it to happen you actually need to wait, that can't happen on a non-empty Stack, only in an empty one.
So the real situation is something more akin to:
Stack is empty.
One fiber is waiting on pop
Another fiber pushes A, B, C, concurrently with pop is cancelled, and to another push(D)
The end result may be something like: C, D, B, A
Which, yes, feels wrong, but in a highly concurrent scenario, I'm not sure what else to do, at least the element didn't got lost and the overall priority is mostly preserved.
There was a problem hiding this comment.
Is your scenario possible with pushN(A,B,C), or just a series of push()?
There was a problem hiding this comment.
It is possible with pushN sadly, for series for pushs I don't mind since if they are all concurrent then the right order is undefined anyway AFAIK.
But for pushN I am indeed sad that it can lead to that error, the thing is that pushN is atomic in deciding which waiters to await, but it can't wait for them to be awakened before modifying the State.
