[openbeosnetteam] Re: Dragonfly or FreeBSD nestack? was Re: Mailing lists and network team questions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 16 Mar 2006 14:47:18 +0100 CET
Waldemar Kornewald <wkornew@xxxxxxx> wrote:
[...]
> Hopefully, that does not make Haiku very unstable... Also, I don't
> like
> "hacky" solutions. If it's done then it must be done right. I'm not
> sure
> whether we want to have LWKT for R1. What do the other Haiku
> developers
To make this short: we won't have this in R1.
[...]
> I can only say that even my (unfinished) PPP stack implementation
> uses
> LockWithTimeout (in one place) to get around dead-locks. I'd like to
> rewrite the whole PPP threading code into something much simpler.
> Even
> if that means it becomes less multi-threaded...but first we need a
> working netstack.
Actually, locking really isn't that hard in most situations. If you
need to prevent deadlocks this way, I would recommend to redesign your
locking.
[...]
> I don't see what you mean with it looking like Big Giant Lock. Could
> you
> explain to me what exactly you meant? Simply the fact that threads
> stick
> to a CPU? Just distribute more threads across CPUs...
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.
IOW it's like a disable_interrupts()/restore_interrupts() pair with the
exception for real interrupts. So in order to get this working
correctly, you would need something like a fault handler resp. a try/
catch block like this:
try acquire token {
1) update local references
2) do my work
} catch {
go back to 1)
}
Since this mechanism doesn't exist, and since mutexes allow you to
interrupt a thread unconditionally (by any thread) they scale much
better and allow for real-time threads whereas lwkt does not.
Because of this, IMO tokens are generally worse than mutexes - they
just solve one problem much better, ie. the problem of deadlocks. IOW
you should use tokens only when you can't solve deadlocks by design, or
if solving a deadlock by design would be too expensive.
Also, the argument that tokens work better than mutexes because "a
function needs to know which mutexes are held by irrelevant code" can
IMHO be greatly relieved by the following:
a) when you need the same locks, code is usually not that irrelevant
(there are exceptions to this, of course, but they should be pretty
rare)
b) you have a similar situations with tokens: if you call any other
function while you have a token, you must refresh your local data, as
you can't know if this function needed to acquire a token or not.
Hope that helps.
> Please vote now! :)
> IMHO: Let's go for tokens (LWKT) and DragonFly because
> 1. we get a good, existing, usable solution (BSD license)
> 2. tokens are more flexible than the other ones
> (e.g.: they can implement RCU-like operation)
> 3. LWKT scales very well
I think my opinion on that should be clear by now :-)
Bye,
Axel.
Other related posts:
