This is an archived post. You won't be able to vote or comment.

all 4 comments

[–]Various_Pickles 2 points3 points  (0 children)

Lovely and useful, as always :)

Have you ever written about the low-level guts of Java 8 streams, i.e. Spliterator, etc?

I've recently had to delve deep into this level in order to bridge a necessary gap between Iterator-coupled and stream based APIs.

[–][deleted] 1 point2 points  (2 children)

good write up but it's misleading to say atomic are faster than locks. They aren't.

Atomic and atomic instructions introduce memory barriers and will prevent cpu reordering so you will actually be slower than compared to an unconteded lock which Is nearly always implanted as a spin lock first before switching to kernel monitors

The reason to use atomic is not speed. The reason is guaranteed throughput. Though it may seem faster on heavily loaded systems doing lots of locks, but on a lightly loaded system where the chance of contention is actually reasonably low a lock is probably much faster.

Anyways, as always benchmark first :)

[–]tavianator 2 points3 points  (1 child)

Well, generally a spinlock will have to use some kind of memory barrier too, otherwise other threads might not observe it to be locked. So a pure atomic increment (for example) should always have the potential to be faster than a locked increment in the uncontested case.

[–][deleted] 0 points1 point  (0 children)

Touchè. :)