Re: locking

From: Robert Watson (rwatson_at_FreeBSD.rg)
Date: 09/24/04

  • Next message: B: "Re: IPv6 route mutex recursion (crash) and fix" 
    Date: Fri, 24 Sep 2004 14:07:28 -0400 (EDT)
To: Waldemar Kornewald <Waldemar.Kornewald@web.de>

    On Thu, 23 Sep 2004, Waldemar Kornewald wrote:

    > we at the Haiku networking team are considering a port of your 5.3
    > netstack because it is thread-safe and making the old one (4.x, I think)
    > thread-safe is probably a much bigger task.
    >
    > Now, I saw that the routing code seems to use macros for the locking
    > code. Do you use macros everywhere?
    >
    > We would prefer having native threads and locks. Haiku only has
    > semaphores, not mutexes, is that a problem?
    >
    > Could you think of some other difficulties we could run into when
    > porting it?

    There are some sections of the network stack, such as the KAME IPSEC
    implementation, parts of IPv6, and some device drivers, which are not yet
    completely MPSAFE. This may or may not be an issue depending on what
    your requirements are. If you have any bug fixes or improvements, we
    would love to hear about them -- right now our locking is fairly
    coarse-grained but we'll be looking at contention issues over the next few
    months to see how best to refine our locking strategy.

    Regarding synchronization -- semaphores can be used to implement mutual
    exclusion, and so you could simply implement the locking macros in terms
    of semaphores rather than mutexes.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Principal Research Scientist, McAfee Research

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

  • Next message: B: "Re: IPv6 route mutex recursion (crash) and fix"

    Relevant Pages

    • Re: file offset corruption on 32-bit machines?
      ... I can easily imagine such a program. ... The easiest way to imagine a program not doing locking and being useful ... anyway (as long as the kernel is thread-safe) is to use the same arguments ... But he notices that the corruption isn't consistent with that hypothesis. ...
      (Linux-Kernel)
    • Re: Concurrency and delegates
      ... thread-safe, people do actually do _something_ like this. ... One technique I've seen suggested doesn't use locking at all. ...
      (microsoft.public.dotnet.languages.csharp)
    • Automatic access serialization
      ... I have a number of objects that are not thread-safe - no locking ... But I want to use them in a thread-safe way. ... The calling thread may acquire the lock multiple times, ... this only works for old-style classes. ...
      (comp.lang.python)
    • Re: Concurrency and delegates
      ... Is there some reason I'm not ... I'm not really clear on why that's considered thread-safe, but it's apparently common enough that the question of the assignment to a local variable being optimized out has come up before. ... Unfortunately, I don't recall any thread that ever provided any conclusive statements one way or the other on either issue (whether the technique works, and whether it can be accidently defeated by the optimizer). ... The only discrepancy would be the use of "this" as opposed to a dedicated object instance for locking. ...
      (microsoft.public.dotnet.languages.csharp)
    • locking
      ... we at the Haiku networking team are considering a port of your 5.3 ... thread-safe is probably a much bigger task. ... I saw that the routing code seems to use macros for the locking ...
      (freebsd-net)