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

Re: A Quick Question about Threads

Expand Messages
  • Jonathan Biggar
    ... One use case for that that I m aware of is when you want to have multiple concurrent searches/modifies in a tree datastructure. You can lock a parent node,
    Message 1 of 16 , Jul 31, 2003
    • 0 Attachment
      Jason Winnebeck wrote:

      > The drawback is that you can't do
      >
      >something like this with the RAII methods.
      >
      >mtx.lock();
      >mtx2.lock();
      >mtx.release();
      >mtx2.release();
      >
      >But I've never seen a case so far where I'm required to do that.
      >
      One use case for that that I'm aware of is when you want to have
      multiple concurrent searches/modifies in a tree datastructure. You can
      lock a parent node, scan the children nodes to find the one you want,
      lock the child and then release the parent so that another search can
      get to a sibling object before you are finished with the child node.

      --
      Jonathan Biggar
      jon@...
      jon@...
    • Richard Howells
      Mark, You may be in good company here. There is a strong myth, that has been running for years, that a Win32 critical section is a way of obtaining *exclusive*
      Message 2 of 16 , Aug 1, 2003
      • 0 Attachment
        Mark,

        You may be in good company here. There is a strong myth, that has been
        running for years, that a Win32 critical section is a way of obtaining
        *exclusive* use of the CPU. It's just plain wrong, but there are a
        surprising number of folks who believe it. From that thought, on a
        uniprocessor, everything else *would* stop when a thread entered a critical
        section.

        In a previous life you were likely unlucky enough to get exposed to someone
        who told you this.

        Best - Richard

        ----- Original Message -----
        From: "Mark Sizer" <yg-boost-users@...>
        To: <boost-users@yahoogroups.com>
        Sent: Friday, August 01, 2003 12:10 AM
        Subject: [Boost-Users] Re: A Quick Question about Threads


        >
        >
        > Jason Winnebeck wrote:
        >
        > > Mark Sizer wrote:
        > >
        > >
        > >>Generically, the difference between critical sections and mutexes is
        > >>immense. In terms of implementation, one never knows.
        > >>
        > >>A critical section blocks EVERYTHING else in the process. A mutex only
        > >>blocks things that are waiting on that particular mutex.
        > >>
        > >
        > > Are you absolutely serious/sure about that? I've been using critical
        > > sections becauase I couldn't find a reason to use mutexes. So far I've
        > > only run my program on single processor machines (where it probably
        > > doesn't matter), but I'd hate to think I would have a huge amount of
        > > contention on multiprocessor machines.
        > >
        > > I can see how crit secs can be faster on a single CPU machine with those
        > > semantics, because when you schedule the process, you just decide to
        > > only schedule that thread. And on a single CPU just setting a flag
        > > should work and be safe to do.
        > >
        > > Jason
        > >
        >
        > I wouldn't bet my life, or even a paycheck on it, but I'm pretty sure.
        > It may be a distinction that some book made years ago that has stuck in
        > my head.
        >
        > Here's MSDN's summary (not that I'm claiming MSDN is authoritative):
        >
        http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp
        >
        > <quote>
        > Critical section objects provide synchronization similar to that
        > provided by mutex objects, except that critical section objects can be
        > used only by the threads of a single process. Event, mutex, and
        > semaphore objects can also be used in a single-process application, but
        > critical section objects provide a slightly faster, more efficient
        > mechanism for mutual-exclusion synchronization (a processor-specific
        > test and set instruction). Like a mutex object, a critical section
        > object can be owned by only one thread at a time, which makes it useful
        > for protecting a shared resource from simultaneous access. There is no
        > guarantee about the order in which threads will obtain ownership of the
        > critical section, however, the system will be fair to all threads.
        > Unlike a mutex object, there is no way to tell whether a critical
        > section has been abandoned.
        > </quote>
        >
        > The efficiency issue implied here could be that mutexes can be named
        > objects shared across PROCESSES, not just threads within a process. That
        > would not apply to boost::mutexes - they're not named.
        >
        > The Win32 critical section API does seem to imply that there are more
        > than one of them - otherwise why pass a pointer?
        >
        > A google search of "POSIX critical section" turned up the fact that
        > POSIX mutexes are generally implemented under Windows as CriticalSections.
        >
        > It's looking like a case where the terms are interchangeable without a
        > VERY specific context. It looks like I'm wrong :(
        >
        > - Mark
        >
        > P.S. I checked a couple of old textbooks I have on my bookshelf and I
        > couldn't find the distinction I recall, either.
        >
        >
        >
        >
        >
        > Info: <http://www.boost.org>
        > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
        > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com>
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
      • Jason Winnebeck
        ... Mark, a tip on that. I don t know if this applies to boost mutex or not, but if their system is like mine, then you can declare _mutexStop with the
        Message 3 of 16 , Aug 1, 2003
        • 0 Attachment
          Mark Sizer wrote:
          > static bool ReceiverBody::bShuttingDown()
          > {
          > bool bLocalStop = false;
          > { boost::mutex::scoped_lock lockStop( _mutexStop );
          > bLocalStop = _bStop;
          > }
          >
          > return bLocalStop;
          > }
          > Note that this can't be const, even though it sort-of is. It modifies
          > the mutex, even though that doesn't matter to the logical state of the
          > object.

          Mark, a tip on that. I don't know if this applies to boost mutex or
          not, but if their system is like mine, then you can declare _mutexStop
          with the mutable keyword. Then you can declare the method bShuttingDown
          as const. At first it might seem like a bad thing, saying const when
          you really don't mean it, but I believe that for member functions const
          means that the state of the object does not change as a result of the
          function -- and it won't, because the state before and after is the same.

          Jason
        • Jason Winnebeck
          ... It looks like you probably saw this already and changed your mind halfway throught he post, but did you read the last paragraph? When a critical
          Message 4 of 16 , Aug 1, 2003
          • 0 Attachment
            Mark Sizer wrote:
            > I wouldn't bet my life, or even a paycheck on it, but I'm pretty sure.
            > It may be a distinction that some book made years ago that has stuck in
            > my head.
            >
            > Here's MSDN's summary (not that I'm claiming MSDN is authoritative):
            > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/critical_section_objects.asp

            It looks like you probably saw this already and changed your mind
            halfway throught he post, but did you read the last paragraph?

            <quote>
            When a critical section object is owned, the only other threads affected
            are those waiting for ownership in a call to EnterCriticalSection.
            Threads that are not waiting are free to continue running.
            </quote>

            Jason
          • Alexander Terekhov
            Mark Sizer wrote: [...] ... [...] ... I bet all my kids, a book was about OS/2 [RIP]. ;-) http://groups.google.com/groups?selm=3D52FB63.7B95E08%40web.de
            Message 5 of 16 , Aug 1, 2003
            • 0 Attachment
              Mark Sizer wrote:
              [...]
              > >>A critical section blocks EVERYTHING else in the process.
              [...]
              > P.S. I checked a couple of old textbooks I have on my bookshelf and I
              > couldn't find the distinction I recall, either.

              I bet all my kids, a book was about OS/2 [RIP]. ;-)

              http://groups.google.com/groups?selm=3D52FB63.7B95E08%40web.de
              (Subject: Re: "memory location")

              regards,
              alexander.

              --
              http://www.terekhov.de/russian-linux
            Your message has been successfully submitted and would be delivered to recipients shortly.