C++Framework - C++ multi-platform memory-model solution, with Java orientation
MoranTza
You can use all the concurrent concepts laid down by Java-memory-
model.
The idea is smooth transition from Java concurrent programming to C++
concurrent programming.
New Version: 1.4 - High Performance Hazard-Pointer:
Download: http://groups.google.com/group/cpp-framework
We tested this version a lot, so it should much more stable. (I'll be
happy to receive constructive comments, and BUG report)
New features:
1) Added "currentThread" method to Thread.
2) Added "addEndCallback" method to Thread, let you add thread
termination callbacks.
3) Added “nextLong” to Random class.
4) Better thread cleanup
5) Improved Hazard-Pointer performance, and stability. Tested with 128
threads. No memory leaks and competitive performance.
6) More examples how to use the Hazard-Pointers: "LazyList.h",
"LockFreeList.h", "LockFreeQueue.h", and “SimpleLinear.h"
7) Sorry no documentation yet.
8) In next version you can expect Linux-Intel compilation, and
documentation.
Thanks,
Moran Tzafrir.
http://www.cs.tau.ac.il/research/moran.tzafrir/
Chris M. Thomasson
news:0ead0422-0996-4877...@g31g2000yqc.googlegroups.com...
> C++ multi-platform memory-model solution, with Java orientation.
> You can use all the concurrent concepts laid down by Java-memory-
> model.
> The idea is smooth transition from Java concurrent programming to C++
> concurrent programming.
> New Version: 1.4 - High Performance Hazard-Pointer:
[...]
I have not looked at your code yet, however, I was wondering exactly what
you mean by "High Performance" hazard pointer. Do you imply that your
implementation does not need the nasty `#StoreLoad' memory barrier? Check
this excellent SMR implementation out:
http://atomic-ptr-plus.sourceforge.net/design.html
Joe Seigh gets around the `#StoreLoad' by running deferred objects through
two RCU grace periods. I am very interested in how you can claim
high-performance wrt SMR. Also, FWIW, there are patent issues wrt SMR...
MoranTza
Current code is Pre-Beta, but was tested a lot, the benchmark show no
memory leak and good performance.
The major overhead for hazard-pointers comes from scanning the Hazards
in other threads. So this code is optimized (but can be optimized
more, lack of time)
You right I should emphasize the fact that I still not optimized the
memory-barriers, I hope to do that in next (or next next :) version.
Thanks,
Moran Tzafrir.
http://www.cs.tau.ac.il/research/moran.tzafrir/
On Jul 27, 4:14 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "MoranTza" <Moran...@gmail.com> wrote in message
Chris M. Thomasson
> > "MoranTza" <Moran...@gmail.com> wrote in message
> >
> > news:0ead0422-0996-4877...@g31g2000yqc.googlegroups.com...
> >
> > > C++ multi-platform memory-model solution, with Java orientation.
> > > You can use all the concurrent concepts laid down by Java-memory-
> > > model.
> > > The idea is smooth transition from Java concurrent programming to C++
> > > concurrent programming.
> > > New Version: 1.4 - High Performance Hazard-Pointer:
> >
> > [...]
> >
> > I have not looked at your code yet, however, I was wondering exactly
> > what
> > you mean by "High Performance" hazard pointer. Do you imply that your
> > implementation does not need the nasty `#StoreLoad' memory barrier?
> > Check
> > this excellent SMR implementation out:
> >
> > http://atomic-ptr-plus.sourceforge.net/design.html
> >
> > Joe Seigh gets around the `#StoreLoad' by running deferred objects
> > through
> > two RCU grace periods. I am very interested in how you can claim
> > high-performance wrt SMR. Also, FWIW, there are patent issues wrt SMR...
"MoranTza" <Mora...@gmail.com> wrote in message
news:796c5591-b96e-44a3...@d4g2000yqa.googlegroups.com...
> Thanks ... I'll review this before releasing next version...
IMHO, it will be well worth your valuable time and effort.
> Current code is Pre-Beta, but was tested a lot, the benchmark show no
> memory leak and good performance.
> The major overhead for hazard-pointers comes from scanning the Hazards
> in other threads. So this code is optimized (but can be optimized
> more, lack of time)
The overhead of scanning hazard pointers can be moved to a dedicated polling
thread. There is no requirement for actual application threads to perform
the scanning process.
IMVHO, the "major" overhead for hazard pointers is the #StoreLoad membar in
the acquire logic. Frequently executing this membar makes it very difficult
to keep the processors "caches primed" thus depriving your application of
the full benefits of a modern multi-processor system. Think of reader
threads using hazard pointers to iterate a shared linked list. A #StoreLoad
membar would have to be executed for every node in the list. That's a
boatload of overhead.
> You right I should emphasize the fact that I still not optimized the
> memory-barriers, I hope to do that in next (or next next :) version.
You should see the overall performance of hazard-pointer based non-blocking
algorithms skyrocket when you get around to removing that membar. One more
thing, I notice that your using a fixed amount of threads. Perhaps you
should consider allowing the hazard pointer algorithm to be able to handle a
dynamic number of threads.