Re: Question about vZOOM reference handling

Dmitriy Vyukov wrote:
On Jun 5, 2:17 pm, Dmitriy Vyukov <dvyu...@xxxxxxxxx> wrote:

One more question.
Consider next situation. Message-passing system. Producer creates
message. Then producer put this message to two different producer-
consumer message queues which go to two different consumer threads.
When message will be consumed by both threads, it must be deleted.

Can vZOOM handle lifetime management of the message?

It seems for me that the answer will be NO.

If you can use a multi-tailed fifo queue instead of 2 different
queues. Make the queue backward linked and use PDR to keep
track of when to free the nodes. The readers will be lock-free.


As far as I see vZOOM can handle only "weak" references, and for
"strong" references one must use reference-counting anyway.


Another situation.
Graph structure where to node can point several other nodes. And this
links are removed not all at once by one thread, but one by one by
different threads.
Can vZOOM handle lifetime management of the node in graph?
It seems that threads that remove links to node must use reference-
counting. But vZOOM still can be used here for readers.

Am I right?



vZOOM and other forms of PDR are mainly useful in read lock-free
reader/writer solutions. Writers can be lock-free as long as you
have some form of multi-word compare and swap. Usually it's easier
to just use a lock on the writer side. And since the readers don't
need to perform any locking, the lock contention is likely to be
low enough to keep the lock uncontended most of the time and
uncontended locks are pretty efficient. The trick is keeping
contention low.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software. .

Relevant Pages

  • Re: Advice on a multithreaded netisr patch?
    ... Initial receipt and processing of packets on a single CPU ... global write lock, if briefly, for every packet. ... Neither 7.x nor 8.x supports multiple transmit queues as ...
    (freebsd-net)
  • Re: Reducing vm page queue mutex contention
    ... because this lock protects a lot of things: ... I would concentrate on entirely eliminating the use of the page queues lock from pmap_enterand pmap_removes_pages. ... While a mutex pool may ultimately be needed, I would start with a simpler approach and then reevaluate what should be the next step. ... The page queues lock is being used to synchronize changes to the page's dirty field and the PTE's PG_M bit against testing for dirty pages in the machine-independent code. ...
    (freebsd-arch)
  • Re: Buggy IPI and MTRR code on low memory
    ... We could have a separate lock for each destination ... Then the caller could release the lock. ... because it a) makes the caller hang around until the consumer has ... executed and it b) requires that callers still have local interrupts ...
    (Linux-Kernel)
  • Reducing vm page queue mutex contention
    ... because this lock protects a lot of things: ... the page queues lock dependency. ... Add a mutex pool for vm pages to protect the pv entries lists. ...
    (freebsd-arch)
  • Re: Synchronized Collection Recommendation
    ... Let the consumer decide. ... As the answer can help dictate the lock to use. ...
    (microsoft.public.dotnet.languages.csharp)