Not high priority given that I won't suggest users to run any application after receiving an OOM, but still relevant: here an explanation on how it could happen.
It could be easily solved by changing semantic of poll, peek and isEmpty during a resizing:
On an empty q, If the parity bit is just set and the new linked chunk is not yet set, isEmpty should return true and both poll and peek should return null.
This allow a producer index rollback to pass unnoticed because resizing won't make a consumer to believe that there's some data.
Data will be perceived as available just when producer index is further moved (and by consequence, a JUMP ready to be spin-awaited)
TLDR any emptiness check should use both consumer and producer index >> 1 to save considering any parity bit due to resizing
@nitsanw other ideas?
Not high priority given that I won't suggest users to run any application after receiving an OOM, but still relevant: here an explanation on how it could happen.
It could be easily solved by changing semantic of poll, peek and isEmpty during a resizing:
On an empty q, If the parity bit is just set and the new linked chunk is not yet set, isEmpty should return true and both poll and peek should return null.
This allow a producer index rollback to pass unnoticed because resizing won't make a consumer to believe that there's some data.
Data will be perceived as available just when producer index is further moved (and by consequence, a JUMP ready to be spin-awaited)
TLDR any emptiness check should use both consumer and producer index >> 1 to save considering any parity bit due to resizing
@nitsanw other ideas?