Thread: C++ and pthreads ??

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    C++ and pthreads ??

    I have quite well investigated problems dealing with pthreads in C (mutex, alignment, cond_signal ..)
    But I still have to investigate it with C++ !

    (1)What is the same as with C?
    (2)
    What changes?
    What new problems?

    (3)
    What about object (and object methods) sharing?? I guess that an object method from the point of view of sharing is just a pointer to a function so needs no mutex or whatever?
    While instead object variables if shared must be protected by a mutex (may be inside the method used for access)?

    Could you please give hints and links?
    Thank you

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    There really isn't much that changes - C++ is C backwards compatible, so the thread functions themselves will work just the same - they are just C functions that are called from C++.

    Obviously, accessing the same object from multiple threads follow the same rules as any other type of shared data access from multiple threads - you need sufficient locks to make sure that one piece of code doesn't trample some other threads efforts. Methods are functions - the fact that they are essentially function pointers make no big difference to the functionality [as the pointers are never being written, they are generated at compile-time - or, link-time in some cases - but always before the application executes in any sense], so there is no difference between object member functions and any other functions - the function itself needs no protection, but the access within the function may do. It is the same rule as if you pass the pointer to a struct to a function - classes are structs.

    One neat thing is that you can create locks with a constructor and release them with the destructor, something like this:
    Code:
    // Lock.h
    class mylock
    {
       private:
         static SomeSortOfLock lock;
       public:
         mylock() { lock.Lock(); }
         ~mylock() { lock.Release(); }
    };
    
    // Lock.cpp
    static mylock::SomeSortOfLock lock;
    
    // Someother.cpp
    ...
    
    void func()
    {
       mylock lock;
       ... 
       // lock falling out of scope automatically calls the destructor, so no need to "unlock". 
    }
    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Quote Originally Posted by matsp View Post
    There really isn't much that changes - C++ is C backwards compatible, so the thread functions themselves will work just the same - they are just C functions that are called from C++.

    Obviously, accessing the same object from multiple threads follow the same rules as any other type of shared data access from multiple threads - you need sufficient locks to make sure that one piece of code doesn't trample some other threads efforts. Methods are functions - the fact that they are essentially function pointers make no big difference to the functionality [as the pointers are never being written, they are generated at compile-time - or, link-time in some cases - but always before the application executes in any sense], so there is no difference between object member functions and any other functions - the function itself needs no protection, but the access within the function may do. It is the same rule as if you pass the pointer to a struct to a function - classes are structs.

    One neat thing is that you can create locks with a constructor and release them with the destructor, something like this:
    --
    Mats
    Thank you very much, very helpful!

Popular pages Recent additions subscribe to a feed