Re: Rise of the multicore machines

>> I almost forgot
>> 14) tracing GC (e.g. Java lock-free linked lists)
>>
> 15) Yet Another Rabbit (YAR)
>
> Another hat trick. It's secret at this point until I decide what
> do with it (assuming it works). It has the advantage of being
> more portable

That's the route I took with VZOOM; the memory visibility requirements can
be guaranteed to work via. POSIX mutex semantics. So, I can add yet another
pattern to your list:


16) Distributed Proxy Ref-Counting (DPRC)?

Each thread has an array of reference counters that track the total amount
of proxy references there are to an object. Sum of all threads counters is
total proxy count for an object. Two or more objects are allowed to share
the same per-thread reference count. Adjustments to the count can be made
without any atomic ops and/or membars. Repeatedly iterating over a large
shared circular linked-list could be as simple as this:




int loops = 0;
int loop_sync = 8192;
item *f, *nx;

f = vz_persistent_inc( &col.front );

while ( f )
{
nz = vz_persistent_inc( &f->next );

do_work( f );

if ( ! ( (++loops) % loop_sync ) )
{
vz_sync();
}

vz_persistent_dec( f );
f = nx;
}


This simple example happens to voluntary execute a synchronization (membar),
however they can also be tracked by relying on highly non-portable operating
system information, ect... The reason I use the term "persistent" is because
references can exist across calls to vz_sync() and/or operating system
induced synchronizations, also the number of references a thread can acquire
is basically unbounded. IMHO, this is what I think sets VZOOM apart from
most of the schemes that are currently out there. I will be able to provide
some working examples that are based on various Distributed Proxy
Ref-Counting schemes in early December so you can see VZOOM in action...




> and having less patent entanglement problems (unless
> I patent it of course).

Yes. It seems that the claims for most of the relevant patents in this area
are narrowed down to a point where you can slide around "some of them",
indeed... For instance, I can claim that VZOOM requires a thread/processor
in a plurality of threads/processors to periodically, episodically or
randomly execute a "memory barrier". This simple claim is very broad and
doesn't need to be narrowed down to support the patent teachings. It also
did not infringe on existing relevant patent claims...

;)


.

Relevant Pages

  • vZOOM can handle cross-thread long-term references?
    ... It seems that vZOOM *can* handle such references. ... Then producer acquire 2 long-term references to message. ... Then every consumer process message somehow. ...
    (comp.programming.threads)
  • Re: vZOOM can handle cross-thread long-term references?
    ... "Chris Thomasson" wrote in message ... passing system. ... It seems that vZOOM *can* handle such references. ...
    (comp.programming.threads)
  • Re: CK Patent 6967448
    ... >a new patent granted 25 October 2005.... ... This patent has a longer list of references than I have ever ... therefore in the public domain. ... or use e-mail address listed at the Web site. ...
    (sci.engr.lighting)
  • Re: CK Patent 6967448
    ... >>>From the news briefs at www.ledmagazine.com I saw a notice that CK has ... > This patent has a longer list of references than I have ever ... > someone was paying me my usual consulting fee) it would be ...
    (sci.engr.lighting)
  • Re: vZOOM can handle cross-thread long-term references?
    ... It seems that vZOOM *can* handle such references. ... Then producer acquire 2 long-term references to message. ... Then every consumer process message somehow. ...
    (comp.programming.threads)