boost threads

This is a discussion on boost threads within the C++ Programming forums, part of the General Programming Boards category; What does mean to join threads or share their ownership?...

  1. #1
    l2u
    l2u is offline
    Registered User
    Join Date
    May 2006
    Posts
    630

    boost threads

    What does mean to join threads or share their ownership?

  2. #2
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,577
    The term join may not be what you think. It means to join a new thread to the current process. One process can have many threads. It always has one. And you can simulate multi-tasking by creating a new thread and joining it to the current process.

    Shared ownership (in the context of threads. The term also coins a smart pointer technique) goes hand-in-hand with another concept. That of locks. A thread may request two type of locks on a resource (usually an object); shared or exclusive. By far the most usual type is exclusive. In this case any other thread wanting to access that resource will have to wait for the former one to release the lock.

    With shared ownership (very dangerous if one doesn't know what they are doing), a thread that tries to access the shared resource will be granted said access as long as the object doesn't have already an exlusive lock on it. This means more than one thread can access the resource at the same time.

    If any of those threads change the resource state, you will have a very hard bug to deal with. If both threads don't change the resource (they don't for instance alter the state of an object), then it's pretty safe to use.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F.
    The term join may not be what you think. It means to join a new thread to the current process. One process can have many threads. It always has one. And you can simulate multi-tasking by creating a new thread and joining it to the current process.
    Join, as Boost.Threads uses it, means to wait for a thread to finish.

    With shared ownership (very dangerous if one doesn't know what they are doing), a thread that tries to access the shared resource will be granted said access as long as the object doesn't have already an exlusive lock on it. This means more than one thread can access the resource at the same time.
    What's the difference between that and not having any synchronization at all?

    But again, that's not what the Boost.Thread docs mean by shared ownership. They only place they contain this term is in the rationale of making the thread class non-copyable, saying that if several [i]objects[/b] wish to share ownership of a thread (as in, the last of the objects to be destructed will destruct the thread object) they should just use a shared_ptr.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,577
    > What's the difference between that and not having any synchronization at all?

    Well, for threads implementations that allow this, it means you are granted access if you request a shared lock on resource that already has a shared lock or no lock at all.

    > But again, that's not what the Boost.Thread docs mean by shared ownership. They only place they contain this term is in the rationale of making the thread class non-copyable

    I didn't use boost::threads to answer that because the term shared ownership is not know in that implementation. So I just recalled what I have read before about threading implementations.... particularly this document on the open standards website:
    http://www.open-std.org/jtc1/sc22/wg...006/n2139.html
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F.
    Well, for threads implementations that allow this, it means you are granted access if you request a shared lock on resource that already has a shared lock or no lock at all.
    Hmm ... would that be like a single-writer-multiple-reader lock?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,577
    If I get it right, it can be implemented if your first obtain a exclusive lock for the writing. All shared locks will then gain wait state.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 10-17-2008, 12:28 PM
  2. Yet another n00b in pthreads ...
    By dimis in forum C++ Programming
    Replies: 14
    Last Post: 04-07-2008, 01:43 AM
  3. Replies: 1
    Last Post: 12-18-2007, 02:51 PM
  4. problem with win32 threads
    By pdmarshall in forum C++ Programming
    Replies: 6
    Last Post: 07-29-2004, 03:39 PM
  5. Block and wake up certain threads
    By Spark in forum C Programming
    Replies: 9
    Last Post: 06-01-2002, 04:39 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21