Fast lock-based FIFO alias bounded buffer

[Chris Thomasson]

I have only good impressions of your eventcount. It's very simple and
very efficient.

Thank you.

I used it to combine several queues and scheduler for
thread.

That's very good to hear. I am glad that it can be of assistance to some of
your high-end programs.

:^)

As for Boost.Threads I'm not sure. If someone will add event count to
Boost.Threads then he must also add some queues and stacks, and
educate people how correctly use it.

Yeah... That's oh so very true. Humm. Well, IMVHO, I think it could possibly
fit in with C++ simply because its going to standardize low-level atomics
and threading. Programmers are going to actually be able to create standard
non-blocking algorithms; therefore, it would be very nice to also provide a
standard method to apply conditional blocking semantics to them. This is
probably going to sound controversial, but perhaps leaving eventcounts out
of the next C++ standard would be somewhat similar to leaving condvars out
of PThreads; does that make any sense?

:^o

 

[Chris Thomasson]

Do you even know what an eventcount is? Well, it's a general solution
for
adding conditional blocking functionality to existing non-blocking
algorithms. It's kind of like a condition-variable for non-blocking
algorithms. In fact, it would be a great candidate for standardization.
I
should propose it for Boost.Threads. What do you think Dmitriy?

[...]
As for Boost.Threads I'm not sure. If someone will add event count to
Boost.Threads then he must also add some queues and stacks, and
educate people how correctly use it.

Yeah... That's oh so very true. Humm. Well, IMVHO, I think it could
possibly fit in with C++ simply because its going to standardize low-level
atomics and threading. Programmers are going to actually be able to create
standard non-blocking algorithms; therefore, it would be very nice to also
provide a standard method to apply conditional blocking semantics to them.

[...]

On second thought, scratch that idea. As long as Standard C++ provides
mutexs, condvars, atomics and membars, well, that would allow me to create a
100% standard implementation of my eventcount algorithm as-is. Very cool
indeed!

:^D

 

[Chris Thomasson]

Let us see how we can fix the problem pointed out in:

http://groups.google.com/group/comp.programming.threads/msg/c7aca39d932e0e30

The hazard can arise because the access of the array cell is not
included into the critical region. Typical mistake in concurrent
programs which, at the moment, can only be detected by good reviews.

The fix can be along the lines of including the access of the array of
cells into the atomic action:

[...]

Lets see here... On an uncontended access to either the get, or put,
functions you are forcing the use of 4 atomic operations, and 4 memory
barriers; 2 of those membars are #StoreLoad! How in the world can you claim
that this is fast? Heck, I would rather just use a single mutex to protect
the whole thing. That way I only have to use 2 atomic-ops and 2 membars
(only one of those being #StoreLoad) on uncontended case.

 

[Chris Thomasson]

Let us see how we can fix the problem pointed out in:

http://groups.google.com/group/comp.programming.threads/msg/c7aca39d932e0e30

The hazard can arise because the access of the array cell is not
included into the critical region. Typical mistake in concurrent
programs which, at the moment, can only be detected by good reviews.

The fix can be along the lines of including the access of the array of
cells into the atomic action:

[...]

Lets see here... On an uncontended access to either the get, or put,
functions you are forcing the use of 4 atomic operations, and 4 memory
barriers; 2 of those membars are #StoreLoad! How in the world can you
claim that this is fast? Heck, I would rather just use a single mutex to
protect the whole thing. That way I only have to use 2 atomic-ops and 2
membars (only one of those being #StoreLoad) on uncontended case.

Given that, why would I want to use this primitive? I am all for efficient
lock-based algorithms, unfortunately, this has not turned out to be one
them. Sorry.