When to use Globals vs Mailboxes? How to setup re-useable code?

[jnz]

Building my first RTOS application. Using Keil RTX which is CMSIS, but this should apply to really any RTOS. Have a fair understanding of the data transfer and blocking options; Signals, Semaphores, Mutexes, Mailboxes, Messages, Yield, Delay, etc.

I'm not sure when to use globals variables vs directly sending messages/signals/mail between threads. The idea is that depending on who you asking, Globals are a fine option - or the devil in code. On the other hand, if I want my threads to be re-useable I don't really want to make assumptions with messages/mail since I won't know what application they are being plugged into.

For example:

I have an 8channel SPI LED driver. I want to store this thread in LED_Driver.c so I can hopefully plug it into any application that later uses this chip. I just initialize and call it when needed. The thread should take in data to set the LEDs to, should be able to return or send back data about diagnostics. So my immediate options are:

1. There is a global struct. It has the LEDs requested states, diagnostic info, etc. The LED thread is run when called, or run at an interval, which then has to call SPI thread and toss a mutex on that, it reads the struct and stores the result there. Any other thread can set requests then call the LED Driver Thread, or can read the diagnostic results.

2. There is no global struct. But there a local one to my main logic thread. I could pass this pointer over in a message/mailbox to the LED thread, set a signal or a semaphore that I need the thread to do something, it has the data now to do so. Call the SPI thread once or many times depending on how it works with this part. If I needed to send diagnostic data back, I could put it in a mailbox and anyone interested could read it. The issue I with this I don't know who will be reading from the mailbox, when/how often, etc.

Which of these is the better option in the long run? Considering the real application would get much more complicated than this and I want an emphasis on re-usable code for threads and drivers etc?

I'm also confused as to how I might make a thread self-containted and re-usable if I don't know what system it'll get plugged into later. For instance, if I wanted to pack away this LED Driver thread so I could just include it, init, and run in another program, that'll greatly change how I treat the data it reads and writes to and what method I use. Right?

[Buddy]

Use signal blocks which makes your code sequential so there won't be any problem.

You can use globals as last resort only because globals dissassemble into multiple assembly code and interrupts on that or thread switching will ruin the value stored. A work around is used to wrap it around a mutex.

Globals are used when fast programming is needed. But mutex are troublesome to maintain. You run into deadlocks easily. Signals are easy to maintain and plug and go.

Use pointers to pass values between functions is also thread safe.

[nick58]

Last week we experimented little with various RTX communication mechanisms. So I summarize now my impressions, something may not be quite accurate or even applicable for some cases.

The mailboxes require to use the pseudo dynamic memory allocation mechanisms (memory pools) which exposes us to risks of memory leaks. The message queues are better than the mailboxes if you only need to enque/dequeue 32bit integers, otherwise for structures again you will have to use memory pool. And the 32bit integer requires smaller data packing/unpacking and is also strangely complicated (check the rtx code), we decided to drop that too. So, now we will use fifos implemented internally as rolling buffers with critical sections.
Regarding memory allocation - OS Kernel Init still uses the damn memory pools but at least it is expected to be quite tested so I will close my eyes about it 

[monkey]

For what its worth:
not all RTOSs use memory pools.
EMBOS does not, for instance.
Tasks should be chosen to avoid conflicting resources hence avoid mutexes.
EG all IO using I2C on one task
I use a task for debugger
another for app
another for IO
and if use other IO like USB driver then another task.
If you use mailboxes there is always extra overhead.
Use event flags to make one task request IO operation etc. This keeps things really simple.

Hope this helps!

[dotm]

The mailboxes require to use the pseudo dynamic memory allocation mechanisms (memory pools) which exposes us to risks of memory leaks.

Where do you got this information from? In my understanding memory pools are designed specifically to be thread-safe.

[Buddy]

Mailbox sux. Actual implementation requires lots of effort initializing etc.

Another alternative to RTOS is to use statemachine software like matlab or visualstate.
This is mandatory for safety critical applications when you don't want any rogue states in your system.

[nick58]

Where do you got this information from? In my understanding memory pools are designed specifically to be thread-safe.

I was not complaining about thread safety but about the fact that mailboxes require usage of memory pools which may then result in leaks. What I like about the memory pool/box implementation in RTX is that they seem to limit memory fragmentation. I also like the efficient way they are designed, although it is still slower than a simple preallocated rolling buffer...

Posted on: October 17, 2015, 08:56:14 08:56 - Automerged

Mailbox sux. Actual implementation requires lots of effort initializing etc.

Another alternative to RTOS is to use statemachine software like matlab or visualstate.
This is mandatory for safety critical applications when you don't want any rogue states in your system.

You assume some relatively small, simple system without a lot of time to market pressure?

[bobcat1]

Hi
Try using global's as minimum as possible
Use transfer by pointer function to get variable values from other module

All the best

Bobi

[Buddy]

Dear Bobi,

You're talking about function communication right? Because pointers are atomic by nature, once you execute pointer transfer it only takes one clock cycle in ARM MCU.

But thread to thread communication using pointers have problem because the second thread might modify the value in the middle of the first thread modification, thus you still need mutex protection for global variables nevertheless.

Cheers,
Bud