Thread

[beatboxer05]

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

[Cogman]

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.

[CornedBee]

I'd use Boost.Thread no matter what system.

[Cogman]

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)

[since]

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.

[brewbuck]

Isn't opening something a very transient sort of activity? Why would you do that in a thread?

[CornedBee]

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.

[m37h0d]

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

[Cogman]

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.

[brewbuck]

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.

[IceDane]

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.