Re: An atomic lock-free refcounting patent application

Joe Seigh wrote:
Chris Thomasson wrote:

Joe Seigh wrote:

20060037026 Lightweight reference counting using single-target synchronization

I can't get the illustrations to display in my browser so I can't
say anything for sure but you might say it's interesting.



Humm... I would be interested to know if anybody thinks that there could be any infringement issues between my collector:

http://home.comcast.net/~vzoom/demos/pc_sample.c

and the SUN patent application. The form of ref-counting could be considered to be very similar... Any thoughts? My initial thought is probably not.


Their stuff is identical to atomic_ptr except they haven't specified how
the single target synchonization is accomplished. atomic_ptr uses
double wide compare and swap in that case. They implied it was based
on the technique in that paper I mentioned earlier but I'm not sure how
it will actually work. So you have to decide if part of your technique
is similar to the one in that paper.



Okay. The similarities in our algorithms seem to have nothing to do with single-target synchronization. It only has to do with the way are are managing the nodes lifetimes. They make a clear separation in the paper between the single-target stuff and the method used for node lifetime tracking.

The single-target stuff seems to involve alternating between two pointers (active and inactive). They are using the even or odd quality of a monotonic version counter to determine which pointer is active. They modify version counter along with the number of references there are to the node. They read the pointer along with the version count then double-check with CAS to make sure the pointer read is synchronized with the version read. Synchronized loads from multiple location snapshot type stuff. Like their KCSS implementation... I really do need to read through the patent claims.
.

Relevant Pages

  • Re: Global lock contention problem
    ... Access to global data is performed through global pointer. ... looking for solutions using Posix synchronization only. ... Each thread that unregisters with the polling thread shall lock the ... A registered thread acquires persistent references to an object by loading a pointer to object; dependent load barrier; hash pointer to object into index; the indexed counter in prefsis incremented. ...
    (comp.programming.threads)
  • Re: Independent thread fireing events in ATL Service synchronization requirements?
    ... and made my client list a class with synchronization inside ... my guess is that the lock for the COM object ... pointer is not enough and that I would also need to lock ... > the entire loop notifying your objects. ...
    (microsoft.public.vc.atl)
  • Re: Independent thread fireing events in ATL Service synchronization requirements?
    ... You'll need synchronization for your list all right. ... "Phil Ten" wrote in message ... > I remove the pointer from my list in the destructor of the ... >>>>> features to fire events only when possible. ...
    (microsoft.public.vc.atl)