multiple instances of ITC objects in CMSIS-RTOS

Hello,

I'd like to write some reusabel code module to handle e.g. UART ports. Therefore I'd like to create a variable number (based on some kind of define...) of threads dealing with UART port 1,2,3 ... since it is possible to declare CMSIS-RTOS threads with a variable number of instances it could look like this:

#define UART_PORT_NUM 3

osThreadDef(uart_thread, osPriorityNormal, UART_PORT_NUM, 0)

my problem: If I need any kind of inter-thread communication (ITC) object, like mutexes or mail queues, for each of this threads I don't know how to declare them, since osMailQDef, osMutexDef and so on, are not designed with a "variable" number of instances...

Any suggestions?

If I have such a terminal server, I wouldn't want it to increase the priority, since I would want each connection to be fair.

If your advanced pump driver needs multiple threads, then it is a very, very low probability that you would talk about identical threads. So you would want to set up multiple, specific, threads. And you each thread would want to know what specific input/output/synchronization objects to use.

So I would normally do:

create_thread(id_pump1,pump1_addr,pump1_event,pump1_prio,pump1_listener);
create_thread(id_pump2,pump2_addr,pump2_event,pump2_prio,pump2_listener);
...

and would not have a need for multiple, identical, threads operating in an anonymous way on some anonymous pool of other ITC objects.

If a user wants to increase the speed of pump 5, the user needs to be able to address pump 5. So the user needs to have a specific pump 5 control object.

Same if the user wants to get an alarm because pump 2 fails to keep the intended rpm - then the user needs the thread operating pump 2 to know exactly where to send the reports.

That is why you would normally not see a need for an anonymous group of mutex objects. Or of event objects. Or of mail boxes. But while there is regularly a need for an anonymous group of threads.

You are constantly trying to invent some random system that would need a mutex pool. But you aren't managing to move from an invented system to instead describe a real, existing, usage case. While it's trivial to list thousands upon thousands of existing implementations needing a thread pool.

And look back one more time on osThreadDef().

It takes the parameters:

name    name of the thread function.
priority        initial priority of the thread function.
instances       number of possible thread instances.
stacksz stack size (in bytes) requirements for the thread function.

So you specify one (1) priority.
But you can specify multiple instances.

But that terminal server solution can then perform multiple osThreadCreate() in which the last parameter allows each thread to know which UART it is responsible for. And that parameter can be a pointer to a struct that can look like:

struct term_port {
    uint32_t addr;              // Base address of UART.
    osMessageQId send_queue_id; // Where to pick up outgoing messages.
    osMessageQId recv_queue_id; // Where to send received data.
    ...
};

In the end, the rest of the world needs to know where to send data. And where to pick up data. And how to flag events. So the rest of the program needs well defined objects to operate on. So what reason would there be to have a osMutexDef() that takes a parameter "instances"? I either wants to send my output to a specific printer ("office floor 2") or I want to send it to a generic pool and have the first free printer pick up the data. So either I want each printer to have a named queue. Or I want all printers to look in a common queue and the first to grab the data wins.

With the common queue, I expect the printers to be supplying the same service. With the separate queues, I would expect each printer to be able to have different capabilities so I may select a printer that has duplex support. Or photo colors.

In the end, I have to repeat the same thing I said in the previous post. Don't ask for anonymous mutex pools, anonymous queue pools, ... until you actually have managed to find a problem that would be able to take good advantage of such functionality.

The world have had pthreads for a great many years, without anyone actually getting stuck because of such needs.

When you make posts to this thread, you aren't making the posts to an arbitrary pool of queues or trying to take one mutex from an arbitrary pool of mutexes. You post an addresses message reaching a specific queue affecting a specific mutex. The server may be redundant or load-sharing, in which case there is a pool of symmetrical threads listening for incomming data from that queue.

So in the end, the bulk of all functionality around you just happens to be designed around the two basic variants:
- multiple workers load-sharing tasks received from a single boss.
- multiple companies with individual email addresses or phone numbers.

Spend some time with computer-science books and you'll see lots of generic examples of producer-consumer systems, or publisher-subscriber systems. And the thread implementations are designed around these two concepts.

The only companies who likes "random mailboxes" are the spam companies. But the normal need is to have either an addressed push or an addressed pull.

name name of the thread function. priority initial priority of the thread function. instances number of possible thread instances. stacksz stack size (in bytes) requirements for the thread function.

struct term_port { uint32_t addr; // Base address of UART. osMessageQId send_queue_id; // Where to pick up outgoing messages. osMessageQId recv_queue_id; // Where to send received data. ... };