Re: tasksing and TCP sockets

["Rolf" <rolf.ebert_nospam_@gmx.net>]

Stephen Leake wrote:
> "Rolf" <rolf.ebert_nospam_@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.

> > 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.
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.

> 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