Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.development.apps > #663

Re: Multi threaded embedded linux application state machine design

Newsgroups comp.os.linux.development.apps
Date 2014-03-26 16:10 -0700
References <0a9691b3-a57a-40fa-96ea-5314daa87fe6@googlegroups.com>
Message-ID <cbd8e9b2-2fda-41be-ae13-17a10bbc8c20@googlegroups.com> (permalink)
Subject Re: Multi threaded embedded linux application state machine design
From Miloš Rađenović <semicode@gmail.com>

Show all headers | View raw


Hi Hari,
See my comments bellow
On Wednesday, August 21, 2013 2:19:23 PM UTC+2, Hari Prasath wrote:
> Problem definition:
> 
> 
> 
> We are designing an application for an industrial embedded system running Linux.
> 
> 
> 
> The system is driven by events from the outside world. The inputs to the system could be any of the following:
> 
> 
> 
>     Few inputs to the system in the form of Digital IO lines(connected to the GPIOs of the processor like e-stop)
> 
>     The system runs a web-server which allows for the system to be controlled via the web browser.
> 
>     The system runs a TCP server. Any PC or HMI device could send commands over TCP/IP.
> 
> 
> 
> The system needs to drive or control RS485 slave devices over UART using Modbus. The system also need to control few IO lines like Cooler ON/OFF etc.We believe that a state machine is essential to define this application. The core application shall be a multithreaded application which shall have the following threads...
> 
> 
> 
>     Main thread
> 
>     Thread to control the RS485 slaves.
> 
>     Thread to handle events from the Web interface.
> 
>     Thread to handle digital I/O events.
> 
>     Thread to handle commands over TCP/IP(Sockets)
> 
> 
> 
> For inter-thread communication, we are using Pthread condition signal & wait.  As per our initial design approach(one state machine in main thread), any input event to the system(web or tcp/ip or digital I/O) shall be relayed to the main thread and it shall communicate to the appropriate thread for which the event is destined. A typical scenario would be to get the status of the RS485 slave through the web interface. In this case, the web interface thread shall relay the event to the main thread which shall change the state and then communicate the event to the thread that control's the RS485 slaves & respond back. The main thread shall send the response back to the web interface thread.
> 
> 
> 
> Questions:
> 
> 
> 
>     Should each thread have its own state machine thereby reducing the complexity of the main thread ? In such a case, should we still need to have a state machine in main thread ?
Yes, each thread should have a state machine with timeouts on operations.
Of course there should be main state machine. Main state machine except that should be time based with timeouts on states (Request Input GPIO/Web interface/HMI). 
> 
>     Any thread processing input event can communicate directly to the thread that handles the event bypassing the main thread ? For e.g web interface thread could communicate directly with the thread controlling the RS485 slaves ?
My suggest is that you avoid Cluster structure the interaction from web interface should go to main thread state machine, where you can do a queue based on priority. Otherwise you would implement simple override of functionality.
> 
>     Is it fine to use pthread condition signals & wait for inter thread communication or is there a better approach ?
Take a lot at this Example, it's Solaris but it's POSIX thread model so it will work under linux.
http://docs.oracle.com/cd/E19253-01/816-5137/6mba5vq4p/index.html#sync-30944
> 
>     How can we have one thread wait for event from outside & response from other threads ? For e.g. the web interface thread usually waits for events on a POSIX message queue for Inter process communication from web server CGI bins. The CGI bin's send events to the web interface thread through this message queue. When processing this event, the web interface thread would wait for response from other threads. In such a situation, it couldn't process any new event from the web interface until it has completed processing the previous event and gets back to the wait on the POSIX message queues.
That's why you need IPC thread which will do only reading from POSIX message queues there is timeout functionality in place for that.
http://man7.org/tlpi/download/TLPI-52-POSIX_Message_Queues.pdf
52.5.3 Sending and Receiving Messages with a Timeout
> 
> 
> 
> sorry for the too big explanation...I hope I have put forward my explanation in the best possible way for others to understand and help me.
> 
> 
> 
> I could give more inputs if needed.
> 
> -- 
> 
> Regards, Hari Prasath

Kind regards,
Milos Radenovic

Back to comp.os.linux.development.apps | Previous | NextPrevious in thread | Find similar


Thread

Multi threaded embedded linux application state machine design Hari Prasath <gehariprasath@gmail.com> - 2013-08-21 05:19 -0700
  Re: Multi threaded embedded linux application state machine design Jasen Betts <jasen@xnet.co.nz> - 2013-08-22 08:18 +0000
  Re: Multi threaded embedded linux application state machine design Miloš Rađenović <semicode@gmail.com> - 2014-03-26 16:10 -0700

csiph-web