Is wm_lst "thread-safe"?


I do know that there is no threading for the user program… but there must be something like threads in the OS - e.g. for TCP sockets, timers, …

I had some time ago a similar problem on another system, that’s why I’m wondering it my approach would bring up some unexpected problems.

What I’m going to do:

  • open a tcp socket receiving STX/ETX framed messages.
  • if a msg is received completely, it will be removed from the incoming stream passing the msg to a list (wm_lst_t)
  • another part of sw is checking this list for cmds to be executed (since the cmd execution could take its time I’m going to seperate this part from the socket handling).

And I’m wondering, if there is a (integrated?) mechanism for “locking” a list while manipulating it (e.g. add/remove items).

Does anyone have reflected on this?



Hi Heinz,

Open AT ADL mode is a single task environment. The application works as a single task and hence, there is no question about multiple threads of execution trying to manipulate the same data at the same time.

For instance, if you are receiving some data from the TCP socket, then it can be sure that the function to manipulate the data present in the list will not be automatically called untill explicity called from the TCP handler function.

Hence, the application can call the function to process the data in the list only when it knows that the complete data has been received. (I hope that’s a simple application logic).

If you are additing an item to the list, then no other function will be called until the item is completely added to the list. Only after one function returns, another function will be called.

I hope this clears the doubts that you have.

Best Regards,
Open AT Fan.


That’s what I was thinking of another system, too.

I was just wondering if a wm_lst… command can be intercepted by any event. E.g. timer call, tcp acitivity, …

Looks like the answer is no. But there is no way to look into the lib.



Hi Heinz,

As Open AT is a single task, there is no possiblity of multiple threads being executed in it (with the current versions of Open AT ADL mode).

Only when the currently executing function exists, the next function can take over the CPU. You can check this by subscribing to two timers of almost the same timeout interval and in one of the timer handler function, you can put such a logic that it takes some more time to execute that the other. In this case, you can see that even if the timeout of the second function occurs (when the processing was being performed for the first timer function in the handler), the second timer handler function is not called. The second timer handler function would be called only when the first timer handler function exits. In case, you have provided such a heavy logic in the first timer handler function that the calls to the second timer handler cannot be executed at all, you can see that eventually the Wireless CPU would reset due to stack overflow (as the call to second timer handler would be put on stack and will overflow after sometime)…

Hence, please be sure that with the current version of Open AT and ADL mode of application development, two functions cannot be executing at the same time. Please note that I am mentioning only about the normal APIs ( and not the real time APIs like SCTU or low or high level interrupts providing real time capabilities to the Open AT applications).

Hope this clarifies.

Best Regards,
Open AT Fan.