Re: timeout/callout small step forward

On Sat, 29 Mar 2008, Hans Petter Selasky wrote:

Hi,

How does this patch handle when multiple callouts use the same mutex ? Imagine
that two threads are about to lock the same mutex, then the second thread
will get nowhere while waiting for the first thread to execute the callback.

You are worried that there will be too much contention or that there is some correctness issue?

If you're worried about contention, it would seem that most callers use some per-object mutex for the callout. So there isn't likely to be much contention among callouts.


I think the solution is that callbacks are put in a tree. Giant locked
callbacks go all into the same tree. Else the user of callouts is responsible
for making up the tree.

struct callout {
struct thread *exec_td;
struct callout *parent;
};

struct callout *c;

while (c->parent != NULL) {
c = c->parent;
}

if (c->exec_td != NULL) {
callout should go into the same thread;
} else {
pick the next free thread and set "c->exec_td"
}

Callouts that belong to the same tree are run from the same thread. This does
not only apply for callouts, but also multithreaded node systems ...

Yours
--HPS

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: timeout/callout small step forward
    ... most clients will use a per-object lock, except for Giant locked systems. ... How does this patch handle when multiple callouts use the same mutex? ... struct callout *parent; ...
    (freebsd-arch)
  • Re: timeout/callout small step forward
    ... How does this patch handle when multiple callouts use the same mutex? ... I think the solution is that callbacks are put in a tree. ... struct callout *parent; ...
    (freebsd-arch)