Thread

This is a discussion on Thread within the C++ Programming forums, part of the General Programming Boards category; Hello, At the moment I am programming in c++ on a linux based system. Now I want to execute a ...

  1. #1
    Registered User
    Join Date
    Dec 2009
    Posts
    1

    Thread

    Hello,

    At the moment I am programming in c++ on a linux based system.
    Now I want to execute a function with the name open_serial() in a thread
    So that this function runs beside my main programm. Can somebody tell me how to do this because I can't figure it out ?

    Kind regards,

    Niek

  2. #2
    Registered User
    Join Date
    Jun 2008
    Posts
    62
    For linux you'll want to use pThreads. When you compile make sure that you use -lpthread .
    There are lots of tutorials on how to use pthreads, just google it up. pthread_create is the function that you want to use specifically.

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I'd use Boost.Thread no matter what system.
    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
    Registered User
    Join Date
    Jun 2008
    Posts
    62
    Quote Originally Posted by CornedBee View Post
    I'd use Boost.Thread no matter what system.
    If portability isn't a concern, then multithreading using the native OS threading system is much easier, IMO, then getting a working build of boost going. It will also lead to a smaller, faster, solution then one based off of boost.

    I have nothing against boost, it is just far to complicated to get a working build of it. And in threading, you really don't gain much by using boost over the native OS thread calls. (other then easier cross platform support)

  5. #5
    Registered User
    Join Date
    Nov 2009
    Posts
    82
    Threading with Boost - Part I: Creating Threads - antonym

    Hmm, doesn't seem too bad, though I haven't actually used Boost for threading before, I might have to give that a shot just to see how it goes in a larger project.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Isn't opening something a very transient sort of activity? Why would you do that in a thread?
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    And in threading, you really don't gain much by using boost over the native OS thread calls.
    I disagree. You gain a well-designed object-oriented API that allows you things like use function objects as thread functions, have RAII lock objects, and so on. pthreads, while well designed too, is a C API, with all the additional work that brings.

    I personally never had any problem whatsoever building Boost (especially not on Linux - the package manager does the work there), but I've seen too many people have problems to argue the point.
    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

  8. #8
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    839
    Quote Originally Posted by brewbuck View Post
    Isn't opening something a very transient sort of activity? Why would you do that in a thread?
    i'd guess he probably wants to open it and being polling the serial port for incoming data

  9. #9
    Registered User
    Join Date
    Jun 2008
    Posts
    62
    Quote Originally Posted by CornedBee View Post
    I disagree. You gain a well-designed object-oriented API that allows you things like use function objects as thread functions, have RAII lock objects, and so on. pthreads, while well designed too, is a C API, with all the additional work that brings.

    I personally never had any problem whatsoever building Boost (especially not on Linux - the package manager does the work there), but I've seen too many people have problems to argue the point.
    Meh, I guess using something just because it is object oriented doesn't really do it for me.

    Yes some of the locking features are nice, like scope lock, ect. But a well placed mutex will perform exactly the same without the excess overhead. The extra work of pthreads is looking up the API and seeing the exact order of parameters in pThread_create. Sure, you have to use the exact function definition for things to work out, but it really isn't THAT hard to do.

    I can see your point though. Boost is easier to use, and has several features that are quite nice. I just don't see the Speed/niceness trade off as being worth it. To me, native threads are pretty dang simple, they require no extra or special packages, and they are extremely well documented.

    Like I said, if I where to do cross platform threading, it would use boost, all the way. That would keep code much cleaner and more concise, as well as give you the extra little boost bonuses.

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Cogman View Post
    Yes some of the locking features are nice, like scope lock, ect. But a well placed mutex will perform exactly the same without the excess overhead.
    A scoped lock has no overhead. ZERO. You also never have to remember to unlock it, you don't need to wrap every single damn block of code that could throw with a try{}catch{} to unlock the mutex, etc.

    It also acts as a token which proves you have locked the lock. Another function could require you to pass in a scoped lock as a parameter -- not to manipulate it, but just to prove that you have it. Now you have the ability to enforce locking at the API level -- you can't even CALL such-and-such a function unless you've locked such-and-such lock.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Ex scientia vera
    Join Date
    Sep 2007
    Posts
    478
    Quote Originally Posted by brewbuck View Post
    A scoped lock has no overhead. ZERO. You also never have to remember to unlock it, you don't need to wrap every single damn block of code that could throw with a try{}catch{} to unlock the mutex, etc.

    It also acts as a token which proves you have locked the lock. Another function could require you to pass in a scoped lock as a parameter -- not to manipulate it, but just to prove that you have it. Now you have the ability to enforce locking at the API level -- you can't even CALL such-and-such a function unless you've locked such-and-such lock.
    I agree - the way Boost does this is so convenient I literally get a nice warm feeling when implementing threads. You all know it; it's the feeling you get when you feel like you're writing some nicely put-together software.

    I hope I'm not the only one who gets that feeling, heh.
    "What's up, Doc?"
    "'Up' is a relative concept. It has no intrinsic value."

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 02-26-2009, 11:48 PM
  2. Terminating secondary thread from another thread
    By wssoh85 in forum C++ Programming
    Replies: 13
    Last Post: 12-19-2008, 05:14 AM
  3. thread termination
    By arjunajay in forum Windows Programming
    Replies: 3
    Last Post: 06-27-2006, 12:32 AM
  4. pointer to main thread from worker thread?
    By draegon in forum C++ Programming
    Replies: 2
    Last Post: 10-27-2005, 07:35 AM
  5. Critical Sections, destroying
    By Hunter2 in forum Windows Programming
    Replies: 4
    Last Post: 09-02-2003, 11:36 PM

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