[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 
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.


Other related posts: