comp.programming.threads Google Group

Re: lock-free singly linked list design

a...@b.com (Toby Douglass) — Wed, 06 Jan 2010 21:29:49 UT

No - but it's possible; the list elements could each contain an ABA
counter. That would be nice - then there's no 2^11 minimum element
count requirement.
The worse case, as far as I can think of, is a freelist, with a single
element being repeatedly popped and pushed. That way you have the same

Re: lock-free singly linked list design

a...@b.com (Toby Douglass) — Wed, 06 Jan 2010 21:13:41 UT

element.
I'm implementing ATM - if it works (big if) it'll be in the next liblfds
release.

Re: lock-free singly linked list design

a...@b.com (Toby Douglass) — Wed, 06 Jan 2010 21:11:41 UT

But
It's okay - the queue isn't using indexes. It's running off a freelist
and that freelist is using normal DCAS pointer/counter pairs - with full
local pointer length bit widths. The freelist/queue here convert the
pointers into indexes for external users.
Well, you have a cursor, which points to an element - which is to say,

Re: lock-free singly linked list design

n...@spam.invalid (Chris M. Thomasson) — Wed, 06 Jan 2010 21:02:54 UT

[...]
Are you using the per-element ABA counter in the actual stack anchor?
Something like this:
[link]
This definitely reduces the chances of ABA problem. Also, keep in mind that
you do not need to increment the ABA counter in push, and you don't even

Re: lock-free singly linked list design

a...@b.com (Toby Douglass) — Wed, 06 Jan 2010 20:52:26 UT

*in
Yup!
Correct. *Exactly*.

It wasn't my aim to target that machine type particularly; what happened
was that I was exploring the line of thought 'well, how can you know
that the element is still valid' and I just went were it took me - and
where it's taken me, right now, this time, is a design which requires 64

Re: lock-free singly linked list design

n...@spam.invalid (Chris M. Thomasson) — Wed, 06 Jan 2010 20:03:50 UT

[...]
I guess it would not be wise to store a pointer to an object in an element.
I think I would need to see a legitimate usage example in order to clear my
thoughts Toby.

Re: lock-free singly linked list design

n...@spam.invalid (Chris M. Thomasson) — Wed, 06 Jan 2010 20:01:16 UT

[...]
What about the ABA counters in the queue itself? Why would a 21-bit counter
be too small for a stack, and be okay for a queue?
How would the user process the read data? Within the DWCAS loop, or after
the DWCAS loop succeeds? In either case, the object can be removed and
reused. AFAICT, this design does not prevent a user from operating on

Re: lock-free singly linked list design

n...@spam.invalid (Chris M. Thomasson) — Wed, 06 Jan 2010 19:44:27 UT

Ahh. I missed the fact that the user data is embedded within the
double-word!
You mean it allows one to access elements in a stack and atomically verifies
that they are still indeed in the stack and NOT in the freelist at the time
of verification right?
Humm, I am not exactly sure if this is very practical or not. Was this

Re: lock-free singly linked list design

a...@b.com (Toby Douglass) — Wed, 06 Jan 2010 07:54:00 UT

the
When a thread has to verify an element is valid, it will be doing so
because there is data is wishes to obtain from that element; and that
data is either the pointer to next, the ABA counter of next, the user
data in the element, or finally, the ABA counter of the element (with a
view to bumping it, as the first stage of a delete).

Re: lock-free singly linked list design

n...@spam.invalid (Chris M. Thomasson) — Tue, 05 Jan 2010 23:14:15 UT

How would you handle issue in which Thread A verifies that an element E is
valid, then right before it tries to dereference the pointer, Thread B pops
E from the stack, bumps the aba counter and inserts it into a freelist. Now,
Thread A dereferences E and operates on state of a node that is in the

lock-free singly linked list design

a...@b.com (Toby Douglass) — Tue, 05 Jan 2010 21:19:27 UT

I've been thinking about lock-free singly linked lists.
I've had a thought or two. I will fall off my chair if any of this is
original. What I would like however is to see what you guys think,
since it's nicer to find mistakes *before* you've put in hours and hours
of implementation work.
Having looked somewhat at the literature, there seem to be a number of

Internet : Learn How To Use It .

m.50ah...@gmail.com (BEAN) — Tue, 05 Jan 2010 19:51:51 UT

Internet : Learn How To Use It .
Features :
E-Mail .
Chatting .
Upload , Download and Share .
Blog or website creation .
Earning schemes .
Check all of these in one place at
[link]

Re: Avoiding atomic decrement in final ref counting release

terek...@web.de (Alexander Terekhov) — Mon, 04 Jan 2010 15:21:40 UT

It depends on performance test case of course.
No way unless x86/x64 already introduced CHEAPLOCK prefix instruction or
something like that. ;-)
regards,
alexander.

Re: Avoiding atomic decrement in final ref counting release

ranisharon...@gmail.com (Rani Sharoni) — Mon, 04 Jan 2010 14:57:33 UT

Much better? what is the perf diff compared with full barrier?
Thanks.
Is this the same as InterlockedIncreament on x86/x64 (running windows)
as the memory model is conservative and assure visibility regardless
of interlocked-ops? If not, is there a way cheaper than interlocked-op
to express your AddRef on x86/x64?

Re: Avoiding atomic decrement in final ref counting release

terek...@web.de (Alexander Terekhov) — Mon, 04 Jan 2010 13:22:27 UT

[...]
Yep but it is unnecessary heavy. InterlockedDecrementIfGreaterT hanOne()
with release on success and acquire on failure would do it much better.
Yup.
void AddRef() {
atomic_fetch_add_explicit(&m_r ef, 1, memory_order_relaxed);
regards,
alexander.