Re: GNAT and Tasklets

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7190 bytes --]


"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:m6uast$1rh$1@dont-email.me...
> On 2014-12-18 00:58, Randy Brukardt wrote:
...
>>> Usually we set up a socket, globally, in a package body.
>>>
>>> One task does a blocking select() - thus hanging on it - for say 5-30 s.
>>
>> Here's the problem, you're thinking at much too low of a level. The 
>> Claw/NC
>> sockets libraries abstract sockets comminucation into an I/O model (no 
>> such
>> thing as "select"!). And the implementation can avoid actual blocking 
>> (even
>> though at the call level you will see what appears to be blocking).
>>
>>                      Get (My_Socket, Timeout => 30.0, Item => Buffer, 
>> Last => Last);
>>
>> This will appear to block for 30 seconds, but it surely doesn't have to 
>> be
>> *implemented* that way.
>
> But then you get to poll, no?
> well that will do it of course.

(Careful) polling is better, IMHO, no matter what you're doing. Timeouts 
were very poorly implemented on Windows (perhaps that's been fixed), so 
things could block for long periods even with short timeouts. (DNS queries 
for instance, always seem to block for 30 seconds no matter what timeout is 
used.)

For something like sockets, which are relatively slow compared to the 
computer, polling has no visible effect on performance and ensures that 
nothing will get starved.

If you're using a high-level communication library (not some low-level 
sockets bindings - yuck!), how that's implemented is invisible to the 
client. They shouldn't care.

>> I don't see any sense to the other tasks that you have (I realize I don't
>> understand the precise problem that you are trying to solve). But it all
>> seems WAY too low-level to me;
>
> Not really
> Task 1 is for just receiving data,secure it, and notify others.
> Task 2 is to serialize _writes_ to the socket.
> PO's cant be involved in potentially blocking stuff.

As I noted later, there should only be one task reading/writing the socket 
at a time. Unless, of course, the Ada binding is documented to do the 
locking needed to support that. That's true of *any* Ada object -- without 
documentation and/or code to manage it, it should be assumed to only work 
with one task at a time.

That's of course especially true with a proper higher-level communications 
library, since there almost certainly will be instance data that needs to be 
protected against multi-access.

>>the reason for using such a pattern is that
>> you need high speed responsiveness (far faster than human speeds) --
>
> No. The reason is to have communication logic for say a
> crane or conveyor system in one process, and the business logic
> for that mechanical device in another process.
> (I'm talking about a warehouse control system here,
> with 20-50 daemon processes)

That sounds confused to me. One would expect a communication abstraction 
that all the business logic calls as needed. How that abstraction is 
organized should not be visible to the business logic at all. The 
communication abstraction would just be a set of packages to send and 
receive various kinds of messages.

But we're getting way off-topic here, you're not going to redesign your 
application because I think it sounds confused (and I probably don't know 
enough to make an informed opinion anyway).

 > Having several I/O-processes makes it easy to change the
> way of communication, and still have the same business logic.
> (say an installation from 1992 talks Siemens 3964r/k512 over a serial
> line (its a old standard protocol) and they want to switch plc's
> which talks tcp/ip with another transmission protocol.
> If keeping the messages within the protocol intact,
> then it's just matter of a new I/O process.
> The rest of the system is untouched including business logic processes.
> (I just did this this spring)

I still think this sounds way too low-level. (I shouldn't talk, I tend to do 
whatever works rather than writing a proper abstraction. It's one of the 
reasons I haven't been in a hurry to open-source Janus/Ada; it was designed 
by a bunch of college students that didn't know better. :-)

>> otherwise sticking with a simple I/O model is much easier to understand 
>> for
>> maintenance.
>
> Yes, but it also has to work.

Surely.

>> On top of which, using the same (Ada) object from two different tasks
>> without synchronization is an invalid use of shared variables. Such a
>> program is technically erroneous, and as such, it could do anything at 
>> all.
>
> Hmm, is it?
>
> I got this from stackoverflow.
>
> <http://stackoverflow.com/questions/13021796/simultaneously-read-and-write-on-the-same-socket-in-c-or-c>
>
> "You don't have to worry about it. One thread reading and one thread
> writing will work as you expect. Sockets are full duplex, so you can
> read while you write and vice-versa. You'd have to worry if you had
> multiple writers, but this is not the case."

Sure, the underlying C might be task safe (although I wouldn't trust it 
myself). But I hope you're using a nice Ada abstraction of sockets and not 
just calling raw C routines to do stuff. (If you are, you're hopeless and 
this whole discussion is irrelevant.) And that latter abstraction is only 
safe if it is programmed to be safe (that is, uses locks as needed) or is 
wrapped in a PO to make it safe. Specifically, Claw sockets and it's bastard 
child NC_Sockets are only task safe to the extent that separate tasks can 
operate on separate sockets objects.

> And that is basically what I heard before.
> So it does work, and works well.
> But of course, it may be illegal anyway.
>
>> So I'm dubious that your pattern even works on other compilers 
>> (regardless
>> of the blocking issue).
>
> It did work well with ObjectAda too, but that was 10 years ago.
>
> AlsysAda for AIX did not like this. It had, as Janus has,
> tasking in its runtime, and anything blocking would block all.

Right. And even on the systems where it worked, you're dependent that your 
sockets library doesn't do any buffering (NC_Sockets can), doesn't have any 
local data other than a sockets handle, and the like. A updated sockets 
library might change that behavior.

>> It's unfortunate that Ada doesn't have any static
>> checking for such things, because it's all too easy to write something 
>> that
>> works today but won't work in the future.
>>
>
> Yes, This makes me think that access to it should be wrapped in a PO

I think so. It certainly would be safer that way (it would surely work 
rather than "probably work"). Remember that you can't really find race 
conditions by testing -- they can occur quite rarely (two tasks have to be 
doing exactly the iffy thing at exactly the same time) and usually they'll 
leave no trace other than a malfunctioning system. You could have some and 
not even know it. (Indeed, I'd be surprised if there were more than a 
handful of Ada programs that contain tasks that don't have any race 
conditions. One of the goals of the parallel work is to be able to construct 
programs in a subset of Ada that cannot have any race conditions, and get an 
compile-time error if that is not true.)

                                     Randy.