tasksing and TCP sockets
in [ADA]
|
From: Stephen Leake on 4 Feb 2006 07:48 "Rolf" <rolf.ebert_nospam_(a)gmx.net> writes: > Stephen Leake wrote: >> "Rolf" <rolf.ebert_nospam_(a)gmx.net> writes: >> >> > The main program essentially looks like this: >> > >> > loop >> > Read_Sens; >> > >> > Behave; >> > >> > delay until Next; >> > Next := Next + Period; -- Period == 0.1 sec typ. >> > end loop; >> >> Ok. So Read_Sens runs the h/w abstraction layer, Behave is the >> application layer. > > More or less. Behave also calls a write routine in the abstraction > layer. Ah. That's how it "changes the world". Ok. >> > The world simulation program at the other end of the TCP socket does >> > not know about the internal timing of the application (perhaps I should >> > add a synchronization protocol, now that I think of it) >> >> I'm still not clear where the sockets are. I think Read_Sens reads >> from a socket to get the simulated sensor values. Does it try to read >> data for all variables from the socket _every_ time it is called? Or >> does it check to see if some new data is available? > > Read_Sens reads the hardware sensors in the non-simulated case and > writes them to global variables. It reads them from a protected object > when communicating via TCP. The second task (besides the main program) > continuously reads from the socket and writes to the protected object. "continously" is a dangerous term; that's 100% CPU? I assume this is where the "delay" comes in, and this is actually "periodically". > That second task and the protected object do not exist in the > non-simulated case. > >> Behave writes to a socket for user display? > > and it changes the world in the world simulation. The world simulation > also has a GUI. Ok. >> Then the question is what drives the simulation; does it wait for >> Read_Sens to read data, or just run at some rate? Does the simulation >> react to anything Behave does? >> >> Yes, you need synchronization between the simulation and Read_Sens, >> and possibly Behave. That is probably the root cause of your problem. > > that is certainly true and I have to think about it again. > > No, the root cause of my problem was a buggy socket implementation in > gcc-3.4.4 (at least I think so). I recompiled my program with GNAT GPL > 2005 and it worked without any other modification Ah. Good that it works now. -- -- Stephe
From: Dave Thompson on 6 Feb 2006 00:02
On Tue, 31 Jan 2006 00:59:45 -0600, tmoran(a)acm.org wrote: > >You should _not_ need delay statements. Redesign to be waiting on > >socket completions. > If the allowed response latency isn't terribly short (and it doesn't > sound like it is here) there's nothing wrong with letting the system > buffer up input while the reading task does a delay. Just use a blocking > socket and poll to see if there's more input data available. Remember > that "waiting on socket completions" in Windows means "polling the Windows > message loop for a socket completion message". In Windows-the-GUI, or at least for a GUI task/thread on Windows. But for Windows-the-OS (a non-GUI task/thread or "console" program) plain old recv() and if you wish select() work just fine. <snip> <OFFTOPIC> I feel impelled to re-quote this prior line: > TCP server that simulates the world I realize it makes sense in the context of the OP system description, but just looking at it in isolation reminded me all too forcefully of any number of past project breakdown/deliverable items with demure-looking descriptions that turned out to be disasters. <G?> </> - David.Thompson1 at worldnet.att.net |