Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Re: Threading

Expand Messages
  • c@nautronix.com.au
    =From: ralphamack =--- In extremeprogramming@y..., John Carter =wrote: = On Thu, 14 Feb 2002, Peter Hansen wrote:
    Message 1 of 1 , Jul 31, 1907
      =From: "ralphamack" <ralph@...>
      =--- In extremeprogramming@y..., John Carter <john.carter@t...>
      => On Thu, 14 Feb 2002, Peter Hansen wrote:
      => > I seem to have learned ways of avoiding the real
      => > difficulties that some seem to find lurking in any threaded
      => Where would I find a good discussion of design for avoiding
      =sorrows in a
      => large multithreaded app?
      => Where would I find a good discussion of unit testing threaded
      =I can't answer your questions but here are my rules of thumb:
      =- Use as few threads as possible to accomplish the goal.
      =- Share as little as possible.
      =- Always protect what you share.
      =- Have clear, crisp handoff of ownership of anything else.
      =- Hand off as little as possible.
      =These rules are all geared to reducing the danger zone to
      =something where inspection has a reasonable chance of
      =detecting problems, code that is "too simple to fail".

      i suspect most of this is c++ specific but i'd also add...

      - try really hard not to use any.
      - only lock in your public methods not in your private ones.
      - in your lock class which wraps the system calls assert all
      the error codes. so that when a different object tries to unlock
      a lock it doesnt have you'll know about it fast.
      - beware of statics.
      - understand the difference between variables allocated off the
      stack and ones allocated off the heap.
      - have an entry in the doc section of your class which says whether this
      class is thread-safe or not.
      - pimpl your lock class and make it get its implementation from
      a singleton factory, this way you can register different locking schemes
      or even a NullLock (most useful for debugging).
      - instrument your code as you write it with debug which includes the this ptr
      address (again useful for debugging).
      - use something like purify for debugging thread problems.
      - write specific cppunit tests for thread safety (thanks ron).
      - read comp.programming.threads and its faq

      =Oh - here's another couple:
      =- Don't start multithread development until your management
      =has purchased a multi-CPU system in hand to test on.

      damn straight, unless of course your target hardware is single-cpu :)
      but yeah, anything else would be madness, we had "thread-safe" code
      here for about 4years before we got dual-cpu machines, boy did that
      show up a lot of bugs!

      =A multiprocessor system will find bugs that cannot occur on a
      =uniprocessor. If necessary, force each of the threads to have
      =different processor affinity and give it a load for a couple of days.
      =If there are race conditions to be found, this will usually find
      =- Multi-thread disasters are almost bound to happen when
      =people share the whole model data, using critical sections to
      =protect each piece. Most "quick fixes" where a messy refactoring
      =would be better tend to lead in this general direction. Beware!
      =Using threads is like using fire - you don't obsess over the
      =dangers but you treat it with respect for both its useful and its
      =dangerous potential so it doesn't burn out of control.

      agreed, good advice,

    Your message has been successfully submitted and would be delivered to recipients shortly.