Re: 5.1-RELEASE TODO

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 05/22/03

  • Next message: Sid Carter: "Buildworld failure - at libufs.a"
    Date: Thu, 22 May 2003 13:00:39 -0400 (EDT)
    To: Terry Lambert <tlambert2@mindspring.com>
    
    

    On 22-May-2003 Terry Lambert wrote:
    > John Baldwin wrote:
    >> On 22-May-2003 Terry Lambert wrote:
    >> > You don't care if another CPU re-does the work, so long as it
    >> > re-does it atomically. That makes it thread safe without the
    >> > introduction of locks.
    >>
    >> We aren't talking about re-doing the work, we're talking about one
    >> CPU trying to walk the list while it's an inconsistent state and
    >> walking off into the weeds through a stale pointer. I.e, CPU 0
    >> removes an item from the list while CPU 1 is walking over that item.
    >> Duh.
    >
    > A singly linked list can be maintained in a consistent state
    > at all times, so long as pointer updates are atomic to a CPU.
    >
    > As I said before, this is an order of operation problem, not
    > a locking problem.

    For a single linked-list, yes. For doubly-linked lists (which is what
    I primarily had in mind since most structures I've worked with use
    LIST and TAILQ rather than SLIST or STAILQ) it is a different matter.

    >> > Just because your friend jumped off a cliff...
    >>
    >> So what is your magic solution for making rtld thread-safe when
    >> looking up unresolved symbols on first reference?
    >
    > Change the order of operation. Basic database theory:
    >
    > o write new record
    > o atomically update index to point from old
    > record to new record
    > o remove old record
    >
    > No matter how many time you reenter this, you end up with a
    > consistent view.

    Have you brought this up on the threads@ list? Assuming symbol
    lookup is indeed this simple, then I agree that this algorithm
    seems sound to me.

    -- 
    John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
    "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Sid Carter: "Buildworld failure - at libufs.a"

    Relevant Pages

    • Re: very strange pthread problem
      ... The worker threads need access to a class member function or two. ... STL vector so each index into the vector points to the list of pointers ... it's just storing the pointers to the STL lists and the vector ... Then I moved the whole thing to a single cpu Linux ...
      (comp.programming.threads)
    • SCSI bus reset with Adaptec 29320ALP and Eonstor RAID
      ... I am trying to use a 1.5TB Eonstor raid array with FreeBSD 7.0, but I don't understand whether it is the raid or the scsi card or something else that is causing the computer problems when accessing the raid. ... CPU: IntelXeonCPU 3.20GHz ... Kernel Free SCB lists: ... Sequencer Complete DMA-inprog list: ...
      (freebsd-stable)
    • Re: very strange pthread problem (solved)
      ... The worker threads need access to a class member function or two. ... STL vector so each index into the vector points to the list of pointers ... it's just storing the pointers to the STL lists and the vector ... Then I moved the whole thing to a single cpu Linux ...
      (comp.programming.threads)
    • another crash failure with 2.6.36-rc3 vmcore
      ... Improve scalability of files_lock by adding per-cpu, per-sb files lists, ... A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs ... +#ifdef CONFIG_SMP ...
      (Linux-Kernel)
    • [patch 3/4] fs: scale files_lock
      ... Improve scalability of files_lock by adding per-cpu, per-sb files lists, ... A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs ...
      (Linux-Kernel)