Inter-task Communication Pros & Cons & Best Practice

[ChrisDanson]

Hi,

I am trying to understand the pros and cons of threads of execution providing services for one another via intertask messaging, against simply making specific functions rentrant safe and allowing them to be called from any where in a multi-threaded environment.

I am really interested to understand some real life practical examples (both good and bad) that people have come across.

To my mind it looks like a balance between good design and performance. Where something needs to be done very quickly, direct function calls seem sensible. Intertask messaging feels nicer to me from a design point of view because you are encapsulating functionality inside a thread of execution and hiding the implementation of the services it provides. When the implemenation of services changes, the intertask messaging may largely remain unchanged.

So please step forth with your rules of thumb, and principles of best practice.

All insight greatfully received.

 

[xwb]

What environment are you using? Windows has a lot more intertask/thread comms than Unix.

Is it just single machine or multi-machine?

 

[ChrisDanson]

I'm working on Set Top Boxes with VxWorks as the Rtos. I work mostly on a middleware platform which calls down into a porting layer that sits above the STB manufacturers code which I guess includes device drivers for everything on a STB. The middleware is multithreaded.

 

[Diancecht]

Well, reentrant functions are a good choice when you don't have another one. Plus the lack of reusability, they need more testing as they are just your implementation without any bakcup.

If you're using VxWroks, it has built-in intertask messaging that, appart from being easier to desing and reuse, they are reliable as they have been widely tested to be included into an RTos core.

Cheers,
Dian

 

[xwb]

Providing services are OK as long as that is all they do. Normally when the program is being written and the author has a clear mindset, they are clear and well defined. The problem comes during maintenance. If someone inadvertently sets the wrong variable or just as a short cut, does something extra instead of providing a new service it can go horribly wrong and is very difficult to trace. With messaging, you do not get this problem.

There are two forms of messaging: one does immediate execution (send), the other sits in a queue and is processed when the other task is ready (post).

I'm not familiar with VxWorks and I don't know whether it provides one or both those techniques. With Windows there is Send and Post for the two methods. Most Windows programmers are not used to things being done later. They assume things are done immediately so they use Send. On XWindows (Unix), it tends to be Post and it gets very messy when Windows programmers attempt to code round the post and make it a send. Send behaves like a service in that the work is done by the thread doing the sending. You can write a single threaded program using send. Post tends to be done by the thread receiving the message.

Send is basically a form of late binding V-table which doesn't crash if the function is missing.

 

[ChrisDanson]

Thanks for your useful post xwb and sorry for the late reply. (was on holiday)