http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* a lock-based proxy collector? - 2 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/3b70d0ead8e62e15?hl=en
==============================================================================
TOPIC: a lock-based proxy collector?
http://groups.google.com/group/comp.programming.threads/t/3b70d0ead8e62e15?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 20 2009 6:30 am
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:vYpXm.703$8e4.638@newsfe03.iad...
> "Chris M. Thomasson" <no@spam.invalid> wrote in message
> news:BNpXm.702$8e4.485@newsfe03.iad...
> [...]
>>> Humm, well it seems like a "possible" scheme might be to let the readers
>>> simply load a reference to current collector just like in my first
>>> example pseudo-code. The mutator collects nodes and only frees them when
>>> a threshold is encountered. The mutator could do this by simply
>>> collecting from the _current_ collector instead of the previous one .
>>> Okay, check this scheme out:
>>> ______________________________________________________________________
>> [...]
>>> ______________________________________________________________________
>>>
>>>
>>> Need to think if this can possibly work or not... I will probably model
>>> this in Relacy.
>>
>> I don't think this will work. Need to think some more...
>
> Well, so far Relacy disagrees with me because the following test I modeled
> of the algorithm is churning right along as I type:
>
>
> http://relacy.pastebin.com/f5292fbf4
>
I posted the wrong version damn it! Here is the corrected link:
http://relacy.pastebin.com/f53e494e6
Sorry about that! I am running the test with `RL_FORCE_SEQ_CST' defined in
order to see if the algorithm will work at all.
I don't know about this. I have my doubts on the algorithm.
Oh well.
== 2 of 2 ==
Date: Sat, Dec 26 2009 3:50 am
From: Dmitriy Vyukov
On Dec 25, 4:50 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> The key elements are objects are deferred in FIFO order. After two mutations
> occur, one can pop a node off the FIFO and destroy it because it's
> quiescent. I believe there are many improvements I can make to this
> lock-based collector as well as non-blocking collectors based on the same
> basic logic. I will do further testing with Relacy...
>
> What do you think about this Dmitriy?
I need to think on this.
Currently I am busy with my new CopyOnWrite-MultiVersion-ReaderWriter-
Transactional-Sequence-Lock. Doing tests and benchmarks on 2 processor/
8 core/16 hw threads Xeon and 8 core/64 hw threads UltraSPARC T2. It's
fun to see how traditional mutexes (pthread_mutex_t/pthread_spinlock_t/
pthread_rwlock_t) behave in synthetic benchmarks on such machines :)
--
Dmitriy V'jukov
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment