Ahh, one additional note: creating an inline class implementing a common interface isn’t as useful as it seems. On first sight, it looks good, because we implemented a standard lock, so we can use it with many standard tools for locks, and we inlined it, so it is simply an atomic ref. The problem is: we can’t have both of these features at the same time. If we pass it anywhere where Lock is required, it will be automatically boxed. Inlining works only if storing the lock as the BackOff type specifically. And if we have to represent it everywhere as our own type anyway, then we could at all ski ..read more

I think the disadvantage would probably be a performance hit. I imagine the is check has to do some kind of reflective comparison or something? Where as the first check would be an equality operation, which is just “do these two pointers point to the same place in memory?” The real question is, how much of a performance hit is it to do is, and do you care? I would guess you probably don’t care about the performance hit; most JVM applications are not CPU-bound, but IO-bound ..read more

Yeah I think it’s the best option. Tbh, it sounds like you’re basically describing a Monad. I’ve actually come across the Arrow library before, which seems to do what you would want it to do: Either & Ior | Arrow ..read more

you’re right, fixed the original code. I had my own check() type methods that had identical signature but those fail if condition resolves to true… I’ll post JMH later, try it out and lets see if you see similar gains ..read more

vach: you check if that someone is you, and the assert will throw if it resolves to true… Assert throws if we provide false, not true ..read more

I’ll post JMH later on, i’m pretty sure this was better than yield. The more threads you throw at this lock the better it does than the competition. The tradeoff is reentrancy which I do not care for. Reentrancy is usually a guardrail against bad code… I cannot remember a legitimate use case where I needed to acquire my own lock multiple times, its usually done to save against someone marking everything synchronised ..read more

The code is correct, try running it and it will make sense. if you fail to CAS it means it wasn’t null, someone holds it, thus in the else branch, you check if that someone is you, and the assert will throw if it resolves to true… Arguments against putting an if: you introduce a branch, which can be very expensive if not predictable, so I generally avoid it. an IF will throw an exception which is not something non reentrant locks do, see other JDK locks that do not extend reentrantLock… its users fault for misusing it. -ea is deterministic, it will fail fast when you enable it and it will let ..read more

This isn’t really anything new. lock-free algorithms exists since the beginning of concurrency. They are usually better than blocking the thread if there is a high contention and the operation is pretty quick. Again, I’m not entirely sure about this specific implementation with waiting. My intuition says it makes little sense and is generally worse than alternatives, but I didn’t do any measurements myself ..read more

I assume there was a bug in the code OK, it changes everything if he really meant !== instead of ===. (I tried to highlight the issue in my comment above.) but they don’t matter Yes, provided we apply the === → !== operator change. Although I still think that if the implementation does not support reentrant operation then the reentrancy check should not depend on the runtime settings of the JVM (-ea). maybe I’m missing something here or implementing is wrong Otherwise, the idea is interesting. I would be curious what other concurrency experts think about the “final” implementation. Becau ..read more

First of all, I assume there was a bug in the code and @vach actually meant assert(ref.get() !== thread), not ===. This is only to check that we don’t reenter the lock. Now: snorbi: anything could happen. Maybe your thread is preempted, and the thread currently holding the lock is scheduled for execution and performs unlock(). It could even happen that after this unlocking - and before your thread is scheduled for execution again - yet another thread performs lock() successfully. Yes, all these things may happen, but they don’t matter. The only thing we need to make sure is that we are not ..read more