-2

I have a class that I'm using to manage creation of and destruction of threads that are responsible for sending and receiving CAN messages. I don't know if this is the best way to go about it, so I'm looking for advice on how to manage my threads for send messages and receive messages.

Basically I want spawnThread() to spawn a thread for the object passed to it. so, something to the effect of

spawnThread(T obj)
{
    std::thread (&T::obj, this);
}

My expectation was that I would use the Thread class to manage starting and ending the thread for two separate classes SendMessage and ReceiveMessage. Is there a better way to handle threading for sending and receive messages?

Rethipher
  • 336
  • 1
  • 14
  • You may add a [`std::function`](http://en.cppreference.com/w/cpp/utility/functional/function) member to your `cManageThread`class and pass that one in the constructor. You could design that for inheritance and make that constructor `protected`. – πάντα ῥεῖ Jul 08 '16 at 17:58
  • Can you give an example of how that would be accomplished? I was sort of leaning down the road of templates, but I'm still pretty new to c++, so I'm struggling with getting syntax right. – Rethipher Jul 08 '16 at 18:00
  • It's still not really clear what you actually want to achieve. Do you want to have have a class hierachy? Do you just want a template interface? What should the `spawnTrread()` do? Start a new thread? Then you're probably looking for implementation of thread pool. – πάντα ῥεῖ Jul 08 '16 at 18:15
  • Going to drop a bit of ideology on you: There is no point to creating a thread if you're not going to use it, so `spawnThread` is probably a bad idea. Next point: How do you intend do get this `stopThread` variable into the threaded function? – user4581301 Jul 08 '16 at 18:19
  • So, maybe it's a better idea just to create the thread in the sendMessage class and receiveMessage, and dispense with the idea of managing thread creation from a single class? – Rethipher Jul 08 '16 at 18:25
  • What operating system are you targeting? You may be able to have one thread with the read and write multiplexed by [`select`](http://man7.org/linux/man-pages/man2/select.2.html) or [overlapped IO](https://msdn.microsoft.com/en-us/library/windows/desktop/ms686358(v=vs.85).aspx) – user4581301 Jul 08 '16 at 18:31
  • Take a look at this (http://www.bogotobogo.com/cplusplus/C11/3_C11_Threading_Lambda_Functions.php) it is a very short intro for using threading with lambda functions. Not exactly what you need, but, I expect that it will point you in the right direction. – Andrew Jul 08 '16 at 18:35
  • How low-level is your CAN read and write? Are you implementing a CAN parser at the port level or are you using a CAN protocol library that you wish to thread? – user4581301 Jul 08 '16 at 18:48
  • @user4581301, It's a vector library, vxlapi.lib, which has functions I can call to send/receive messages. I plan to later add j1939 protocol on top of it, but that's a discussion for another day. – Rethipher Jul 08 '16 at 19:04
  • Higher level abstraction than you can `select` on then. Do send and receive guarantee a complete message on each call? – user4581301 Jul 08 '16 at 19:08
  • The send function has a return status that tells you whether the message was sent successfully. The receive message fills a queue. – Rethipher Jul 08 '16 at 19:14

1 Answers1

2

There is no such thing as a Manager pattern in OO. A thread either does a continuous job like waiting for connections or does a single shot job. The last type typically are worker-threads that are reused.

Now coming to the question. Threading does not scale. If you have send/receive tasks, process them in a fixed-size worker-thread pool. As a consequence, your application will be react slower if the workload extends your pool size as new request have to wait for a worker, but it will continue to work.

Johan van Breda
  • 583
  • 8
  • 13
  • Echoing this sentiment: create a queue containing the messages that need to be sent, and, if necessary, a second queue in which sent or returning messages can be tossed. Create a pool of "some *n"* threads which are responsible for sending messages on behalf of anyone who needs a message sent. Each thread waits for a message-request to arrive in the queue, then sends it. Quite probably, you will find that you need only *one* thread assigned to this purpose. (It is common to have a second thread ... usually, only one ... to handle "receiving.") – Mike Robinson Jul 08 '16 at 18:32