[docs / pre-alpha] For my atomically thread-safe refcount library prototype...

Here is a link to a pre-alpha rough draft of some documentation I created that attempts to describe every C API that my currently prototype library exposes: http://appcore.home.comcast.net/vzoom/refcount/doc/ I am going to be steadily adding to this initial documentation over the next week or so. Documentation that covers the C++ API is coming shortly... Well, what do you think of my initial docs on the C API everybody? You think that they are off to a fairly good start? ;^) Anyway, any comments/questions/tips/tricks/criticisms are encouraged and will be highly appreciated! Thank You, Chris Thomasson http://appcore.home.comcast.net/ (portable lock-free data structures)

Ok, now the tricky question, Judiging from the comments on comp.programming.threads, looks like almost everything that falls under lock free is patented. Is the refcount code definitely patent encumbered or there is a reasonable chance that it could be used without falling in the patent swamp? What about the rest of appcore (I would love to use a lockfree thread queue)? And then, what about the license? I suppose you have the intention of releasing at least the refcount code under the boost license, what about the rest of appcore? other than that, great job, I'm definitely not an expert in lock free programming and wouldn't touch the implementation not even with a 100 meters staff, but I would definitely be an user . gpd On 10/24/06, Chris Thomasson <cristom@comcast.net> wrote:
Here is a link to a pre-alpha rough draft of some documentation I created that attempts to describe every C API that my currently prototype library exposes:
http://appcore.home.comcast.net/vzoom/refcount/doc/
I am going to be steadily adding to this initial documentation over the next week or so. Documentation that covers the C++ API is coming shortly...
Well, what do you think of my initial docs on the C API everybody? You think that they are off to a fairly good start?
;^)
Anyway, any comments/questions/tips/tricks/criticisms are encouraged and will be highly appreciated!
Thank You,
Chris Thomasson
http://appcore.home.comcast.net/ (portable lock-free data structures)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"Giovanni Piero Deretta" <gpderetta@gmail.com> wrote in message news:1439aad50610240210n2c9d89cdie5e462fc5f26075e@mail.gmail.com...
Ok, now the tricky question,
Judiging from the comments on comp.programming.threads, looks like almost everything that falls under lock free is patented.
Not everything... yet... ;^)
Is the refcount code definitely patent encumbered or there is a reasonable chance that it could be used without falling in the patent swamp?
http://groups.google.com/group/comp.lang.c++.moderated/msg/744d1fcf97fa9dd9 So far so good. I have recently snooped around some patents and patent applications and have not found anything that claims my prior art wrt the my refcount algorithm; looks like this is going to work out just fine for Boost.
What about the rest of appcore (I would love to use a lockfree thread queue)?
Well, the current version of AppCore includes a full-blown SMR implementation; IBM has a patent application out on it. http://groups.google.com/group/comp.programming.threads/browse_frm/thread/dc... So, I need to strip it completely out of my library, then alls that's left are my inventions, this of course includes the queue...
And then, what about the license? I suppose you have the intention of releasing at least the refcount code under the boost license,
Yup.
what about the rest of appcore?
Humm... Not "exactly" sure yet... A commercial library of mine, called vZOOM, makes use of a couple of my algorithms in AppCore. I currently have a patent application out on vZOOM and it's private at this point. I only released a particular version of it to Sun for their CoolThreads contest; it's one of the four finalists: https://coolthreads.dev.java.net/ So, that could be a little tricky... I really need to make up my mind here... I will have an answer for you fairly shortly... Okay? ;^)
other than that, great job,
Thank You! :^)
I'm definitely not an expert in lock free programming and wouldn't touch the implementation not even with a 100 meters staff, but I would definitely be an user .
That's fine. As a user, you should be able to experience the enhanced scalability, throughput and performance benefits' that some cleverly thought-out lock-free algorithms provide... Indeed!

"Chris Thomasson" <cristom@comcast.net> wrote in message news:ehk5h5$do2$1@sea.gmane.org...
Here is a link to a pre-alpha rough draft of some documentation I created that attempts to describe every C API that my currently prototype library exposes:
Anyway, any comments/questions/tips/tricks/criticisms are encouraged and will be highly appreciated!
Has anybody been tinkering around with this at all? If so, I need some feedback...
participants (2)
-
Chris Thomasson
-
Giovanni Piero Deretta