[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 18 Mar 2006 16:43:22 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> Axel Dörfler wrote:
> > Damn, you still didn't get it :-)
> > CPU affinity *can't* let you simplify your locking model. Only *
> > locking
> > * a thread to a certain CPU can - but that's not a good thing, just
> > an
> > IMO bad solution for a self-induced problem.
> Damn, I didn't get it. :)
> I thought that affinity meant "locking to a certain CPU"...sorry.
CPU affinity just means that the scheduler *tries* to keep a thread to
a certain CPU - if the other CPU has free slots it won't hesitate to
take a thread away from the other CPU, though - ie. you can't use this
for anything, it's just faster, because the CPU's cache is likely to be
trashed less often :)
> >>> 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.
> >> Why performance? Productivity and reliability are my concern.
> > Both are not at all compromised by mutexes. At least it's your own
> > fault if it does :)
> > If you don't think about the performance of a basic solution like
> > this
> > you're simply not thinking far enough, sorry.
> You sounded like "the only reason for us to implement such a more
> reliable scheme would be performance bottlenecks". I got the
> impression
> that being dead-lock free does not interest you very much. IMHO, good
> design alone won't always help. Software is not static. You
> constantly
> change it and in these phases of re-orientation many things can
> break. I
> want to have a solution that is highly parallel and at the same time
> does not break (and is easy to use and fast enough for at least 90%
> of
> all use-cases, I want very much... ;).
As I said, several times already now: you can easily implement
serializing tokens using mutexes. No performance hit at all, and yet,
you can't run into the deadlock problem.
> Mutexes can become a hell. Do you remember the dead-lock I reported
> to
> you about OpenTracker (is it fixed, already)? It was very difficult
> to
> track down (and explain ;). No matter how much time you invest into
> planning you sometimes don't realize that there is an *extremely rare
> *
> and complex 0.001% case that could lead to a dead-lock. Also, new
As I said, software should be designed carefully, and that includes
locking strategies.
Later changes might easily break those, and that's why you have to be
careful with it.
Serializing tokens are no free ticked to reliable code; deadlocking
problems are usually easy to identify and to fix - there are certainly
exceptions, though, but they should always be trackable by software
tools (that we don't have, though).
> developers must spend more time on understanding the software
> (DragonFly
> is many times easier to understand than FreeBSD). Why should we have
> to
> bother about dead-locks, at all (better spend that time on something
> else)?
Well, if Matt Dillon's observations are correct, and FreeBSD "often"
passes mutexes held down to other unrelated functions, there is
certainly something wrong with FreeBSD - but that's a problem they have
grown into, it's not a problem of mutexes in general.
When DragonFly's lwkt provides a solution for this problem, great, but
it's not needed when you don't suffer from problems like these in the
first place. And you usually don't.
Bye,
Axel.
Other related posts:
