Tasking Models

Tasking Models

[Marin D. Condic]

I'm working with the Sparc compiler v2.1.1 under Solaris and I can't
seem to find out much about the tasking model. The documentation
indicates that time slicing can be turned on, but I don't know that this
is the case. What I'm wondering about are the conditions under which the
runtime will decide that a task is blocked and allow another task to
run. Specifically if an I/O call or a TCP/IP call will result in a
blocked task and allow another to run. Does anybody know anything about
the tasking model for this compiler? (it is Ada83)

In the past, when I've cared to find out about it, Ada compilers I've
run under various operating systems do not block on an I/O or other
sorts of OS calls. I know this is legal behavior. I don't know of any
reason why it would be *illegal* for the RTK to consider a task blocked
on an OS call. This would be desirable behavior under lots of
conditions, but it also raises questions about the task safety of the OS
calls being made. If this particular RTK blocks, then one has to wonder
about the thread safety of TCP/IP and file I/O calls under this
particular OS. Anybody know if Solaris makes these things thread safe? A
lot of that probably depends on how they mapped the tasks onto the OS.

What documentation I can find so far is pretty pithy on the subject of
the tasking model (and other things as well :-) If somebody is familiar
with this compiler and can point me in a direction, I'd appreciate it.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Tasking Models

[Gisle S�lensminde]

In article <38FD5045.A42B4406@quadruscorp.com>, Marin D. Condic wrote:
>I'm working with the Sparc compiler v2.1.1 under Solaris and I can't
>seem to find out much about the tasking model. The documentation
>indicates that time slicing can be turned on, but I don't know that this
>is the case. What I'm wondering about are the conditions under which the
>runtime will decide that a task is blocked and allow another task to
>run. Specifically if an I/O call or a TCP/IP call will result in a
>blocked task and allow another to run. Does anybody know anything about
>the tasking model for this compiler? (it is Ada83)
>
>In the past, when I've cared to find out about it, Ada compilers I've
>run under various operating systems do not block on an I/O or other
>sorts of OS calls. I know this is legal behavior. I don't know of any
>reason why it would be *illegal* for the RTK to consider a task blocked
>on an OS call. This would be desirable behavior under lots of
>conditions, but it also raises questions about the task safety of the OS
>calls being made. If this particular RTK blocks, then one has to wonder
>about the thread safety of TCP/IP and file I/O calls under this
>particular OS. Anybody know if Solaris makes these things thread safe? A
>lot of that probably depends on how they mapped the tasks onto the OS.
>
>What documentation I can find so far is pretty pithy on the subject of
>the tasking model (and other things as well :-) If somebody is familiar
>with this compiler and can point me in a direction, I'd appreciate it.

I may be wrong, but there are big chances for that an old Ada83 
compiler produce executables for SunOS 4, which runs on Solaris
in compatibility mode AFAIK. I think I remember that SunOS 4 not 
supported multithreading, so if the compiler makes old executables
there will not be threads available, and the Ada threads will 
block on OS calls.

I either case; many of the OS calls in Solaris (esp socket calls)
are not thread safe, so care must be taken. The thread safeness 
is documented on the manpages on all newer Solaris versions,
and in some cases there are Solaris specific thread safe versions 
of the calls.

--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: Tasking Models

[Marin D. Condic]

Gisle S�lensminde wrote:
> I may be wrong, but there are big chances for that an old Ada83
> compiler produce executables for SunOS 4, which runs on Solaris
> in compatibility mode AFAIK. I think I remember that SunOS 4 not
> supported multithreading, so if the compiler makes old executables
> there will not be threads available, and the Ada threads will
> block on OS calls.
> 
Block as in "stand here looking like an idiot doing nothing while I go
run some I/O chores for you" or block as in "Ada task 1 is blocked for
I/O - Ada task 2 can now charge off and do its thing."?

Behaviorally speaking, it *appears* to be timeslicing at least because
it doesn't seem to starve any of the tasks. Given where the software has
been and where it is going I really need to *know* what the model is or
the assumptions might kill us. If it *is* timeslicing, then under what
conditions might the expiration of a timeslice interrupt the task in the
middle of something important? Do you surround everything with mutexes?
(We don't have the luxury of protected types here and the original
designers didn't have a good grasp of tasking.)

> I either case; many of the OS calls in Solaris (esp socket calls)
> are not thread safe, so care must be taken. The thread safeness
> is documented on the manpages on all newer Solaris versions,
> and in some cases there are Solaris specific thread safe versions
> of the calls.
> 
There may be some man pages out there - I have not checked yet. There
was a "Programmers Guide" and a "Users Guide" book available, but as I
said - very pithy and not nearly enough said about tasking - or other
important issues.

I've been told that TCP/IP would sort it out - no interleaving of
message fragments at least - which would mean that two tasks writing to
the same socket would be O.K. But getting told that by someone is not
the same as reading it in a document written by the good folks who
brought you the software. I lose sleep at night over stuff like this.
:-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Tasking Models

[Simon Wright]

"Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:

> I've been told that TCP/IP would sort it out - no interleaving of
> message fragments at least - which would mean that two tasks writing to
> the same socket would be O.K. But getting told that by someone is not
> the same as reading it in a document written by the good folks who
> brought you the software. I lose sleep at night over stuff like this.
> :-)

That sounds like a design I would lose sleep over .. I guess if you
always write complete messages you would probably be OK, but I've
usually used the "write the message descriptor, then write the
message" style. Still, you really need to see inside that networking
stack.

Re: Tasking Models

[Marin D. Condic]

Simon Wright wrote:
> That sounds like a design I would lose sleep over .. I guess if you
> always write complete messages you would probably be OK, but I've
> usually used the "write the message descriptor, then write the
> message" style. Still, you really need to see inside that networking
> stack.

Well, the software works at the present moment and under the current
conditions, so quite possibly, it is safe. All messages are sent with a
single call - they are not sent in chunks. (At least at the application
level - TCP/IP, of course, can fragment the message.) So I guess as long
as its sent all in one swell foop, we may be all right.

It's not what I would have built, but you often don't have that luxury.
The design is in place and (mostly) working successfully. My inclination
is to leave it alone, but since we will eventually be changing
compilers, it is very important to know what assumptions are critical to
its operation.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Tasking Models

[Marin D. Condic]

Marin D. Condic wrote:
> In the past, when I've cared to find out about it, Ada compilers I've
> run under various operating systems do not block on an I/O or other
> sorts of OS calls. I know this is legal behavior. I don't know of any
> reason why it would be *illegal* for the RTK to consider a task blocked
> on an OS call. This would be desirable behavior under lots of

And speaking of task blocking, OS blocking and timeslicing.....

Can anybody tell me about the behavior of GNAT in these areas? I have
attempted some GNAT/TCP/IP stuff under Win98 and the behavior when tasks
are involved seems to be that the RTK does not recognize that a thread
is blocked when a call is made to TCP/IP. (Other tasks starve). Is this
the same behavior one could expect under WinNT? How about under various
flavors of Unix? Is there some sort of pragma that can be set which
would insist that the RTK use a timeslicing model? (Except for possible
performance issues, this at least can get you around tasks that are
blocked for I/O.)

It might be interesting to take some of the current software I'm working
with and run it through GNAT to see if that would solve some of our
troubles. But before I go unhooking all the system dependencies for a
new compiler, it would be nice to know about how the RTK handles these
things.

Maybe this is all answered in the Super Secret GNAT Documentation, but
perhaps someone will be kind to the lazy and ignorant? :-)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Tasking Models

[tmoran]

> attempted some GNAT/TCP/IP stuff under Win98 and the behavior when tasks
> are involved seems to be that the RTK does not recognize that a thread
> is blocked when a call is made to TCP/IP. (Other tasks starve). Is this
> the same behavior one could expect under WinNT? How about under various

  Are you sure that with Gnat and Win98 one TCP-blocked Ada task
will cause blocking of other Ada tasks?  I don't think that should
happen.  Winsock functions block on a per-thread basis, so the Ada
run time shouldn't know or care whether a particular thread is
blocked on TCP IO - the other threads should continue time-slicing.

  With Windows 3.1, of course, there is only one thread, and you
need to use Windows' WSA functions to avoid blocking it, but I don't
think Gnat even supports 3.1   If you have Claw.Sockets, take a look
at its use of PO_Boxes to use WSA operations to avoid blocking.  In
Windows CE, MS has finally dropped support for the WSA functions,
leaving Windows time-slicing to other threads as the only way to
avoid blocking the entire program.

Re: Tasking Models

[Marin D. Condic]

tmoran@bix.com wrote:
>   Are you sure that with Gnat and Win98 one TCP-blocked Ada task
> will cause blocking of other Ada tasks?  I don't think that should
> happen.  Winsock functions block on a per-thread basis, so the Ada
> run time shouldn't know or care whether a particular thread is
> blocked on TCP IO - the other threads should continue time-slicing.
> 
I have not researched this in-depth. I just wrote a small test program
in which the main program listened for connections and tasks serviced
the connections. The immediate symptom was that the main program hung
waiting for connections while the tasks got starved. I have not had time
to play with this thoroughly, so there may be some error in my code.
However, that was my impression from its behavior - I couldn't get the
tasks to start receiving data once I started listening for the next
connection.

I'm not yet convinced that Win98 does a good job of managing threads.
Perhaps I should try compiling it on WinNT.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================