[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 17 Mar 2006 12:31:32 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Unfortunately, in complex software locking becomes "pure hell". Look
> at
> app_server.
I have to disagree. The locking model of the app_server is just not
very good :-)
We already have a good solution for this, we just haven't realized it
yet.
The deadlocks that happened were mostly just bugs. In a single case I
moved the functionality from one component to another because of a
deadlock - and that was only a good sign that it didn't belong to the
first component anyway.
> > The fact that lwkt a) can't interrupt threads unconditionally while
> > having a token, and b) that it locks them to a single CPU is both
> > not a
> > good solution. It doesn't allow for for short latency thread
> > scheduling
> > for one - only for interrupts. IOW they should only be used for
> > very
> > short critical zones - then they actually have an advantage over
> > disabling interrupts and acquiring a spinlock.
> I agree that under certain circumstances latency could be a big
> problem
> (e.g.: waiting for data from a device), but how often do you have
> huge
> transactions and how often is it impossible to split that into
> multiple
> concurrent (and asynchronous) transactions? In many cases we can work
> around the problem by sending messages. Also, Joseph already said
> that
> DragonFly's netstack rarely uses tokens, at all (probably because of
> CPU-affinity).
Maybe it didn't go through, but CPU *affinity* is a good thing - just
not if you lock a thread to a single CPU. CPU affinity helps to improve
cache usage.
> Semaphores often force us to create huge locked sections (or we're
> too
> lazy to implement fine-grained locking), but this does not at all
> mean
> that we should use the same development scheme for alternative
> implementations.
Can't follow you there. You can use semaphores exactly like serializing
tokens - it only gets different when you have to lock more than one
semaphore at a time. And as I said, you can easily implement
serializing tokens right now, no one stops you from doing so.
> Maybe we can design something that does not have latency problems (or
> we
> can still consider STM)...that must be discussed for R2, at least.
Well, don't hold your breath :)
When we have a running stable system, we'll identify performance
bottlenecks by profiling - and if that should hint us the way to
something like that, so be it.
Bye,
Axel.
Other related posts:
