Multithreaded Realtime OO Modeling
Bill Royal
multithreaded object modeling.We have a specific question that I'd like
to see some discussion on from others with experience doing this sort of
thing in OO systems. When developing an analysis/design model for a
real-time system, using a typical use-case driven, incremental &
iterative methodology, _should threading and concurrency issues be
brought up early in the modeling process_? Or are these implementation
issues that should be addressed at a different phase later in the
process?
One school of thought essentially leads to a model in which each thread
definea a "partition" in which an object or group of objects live --
there is a concept of "ownership" involved between a thread and its
associated objects. A thread of execution running through one of its
objects is unable to invoke methods on another thread's object, mainly
because it shouldn't have a reference to it in this model (although
nothing technical limits from having one). For inter-thread
communication between objects, some other mechanism would be used (named
pipes, signals, sockets, semaphores, etc. - mechanisms typically
provided by the platform or OS).
Another school of thought suggests that threads are mapped based on
logical flows of control through the system, and these flows have no
(direct) correlation to groups of classes or their instances. During
analysis and design, classes are defined with their attributes and
methods, their relationships are established, and an object model
showing static and dynamic views of the system is developed. Threads
are identified later, during the implementation phase. Each thread is
"flowed" through the design model (each of which would become a sequence
diagram in UML), adding necessary attributes and/or methods to each
class in the model to support the thread. Concurrency, synchronization,
and thread-safety issues must be addressed at this stage, so that, for
instance, an object's properties could be locked with mutexes as
necessary or another blocked thread could be made ready to run by the
scheduler. If the RTOS (or other OS) supports thread priorities, this
must also be addressed during the implementation phase.
So, what are your thoughts? Which way is "more" OO? Which is better
for robust, real-time system development? I won't ask people which way
they think is best (although feel free to share if you'd like). But I
would like to see what's worked and what didn't work in other places and
on other systems.
Patrick Logan
: So, what are your thoughts? Which way is "more" OO? Which is better
: for robust, real-time system development? I won't ask people which way
: they think is best (although feel free to share if you'd like). But I
: would like to see what's worked and what didn't work in other places and
: on other systems.
I have not designed any "hard" real time systems, but I have designed
concurrent and distributed systems. To me, design *is* implementation,
and so concurrency and distribution should be a consideration
throughout. That does not mean that every aspect of your system has to
be aware of specific concurrency or distribution mechanisms. (Or
transaction mechanisms either, since that is another aspect of these
kinds of systems). It means they should be *considered* and factored
in appropriately.
If you are interested in concurrency or distribution in your system
there must be either a requirement that demands this consideration
(e.g. the data is in New York and the user is in Hong Kong), or there
is a requirement that demands some performance which in turn may be
met by concurrency and/or distribution. This I think is *proof* that
these issues are requirements-driven and should be carried through
from requirements to design to deployment.
The particular mechanisms you choose can vary. Maybe a good place to
begin for your needs is Doug Schmidt's ACE system and patterns at
www.cs.wustl.edu. Another good source of information is Doug Lea's
Concurrent Java book, which is also really a book of patterns. But as
I said, I don't know how they apply to *hard* real time systems.
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Charles Martin - Sun PS
>
> We're having some internal debate at my company regarding development of
> multithreaded object modeling.We have a specific question that I'd like
> to see some discussion on from others with experience doing this sort of
> thing in OO systems. When developing an analysis/design model for a
> real-time system, using a typical use-case driven, incremental &
> iterative methodology, _should threading and concurrency issues be
> brought up early in the modeling process_? Or are these implementation
> issues that should be addressed at a different phase later in the
> process?
Actually, as I see it, they are *architectural* issues that are
brought up at the beginning of the logical-to-physical mapping. That
is, you
(1) describe the business or engineering process to be performed in
pure domain terms
(2) model that as an initial object domain model
(3) examine and modify that model to ensure that the domain model is
relatively robust to probably requirements changes
(4) apply transformations to the robust domain model to construct the
physical model.
Thomas Hieber
Bill Royal schrieb in Nachricht <3640DB6F...@spicetech.com>...
>One school of thought essentially leads to a model in which each thread
>definea a "partition" in which an object or group of objects live --
<snip>
>
>Another school of thought suggests that threads are mapped based on
>logical flows of control through the system, and these flows have no
>(direct) correlation to groups of classes or their instances.
<snip>
>So, what are your thoughts? Which way is "more" OO? Which is better
>for robust, real-time system development?
I would go for the first approach. We once did the second one, and we
had very severe problems to identify afterwards which data regions had
to be protected. Also I got the impression, when you do a real OO
design, it will be very hard to find separate threads in your code, that
will not have massive amounts of coupling to other objects. And you will
always have to synchonize these interfaces.
In our current project we used the first approach. At the very beginning
we decided how many threads we would need, and what their jobs would be.
We also decided about priorities and sceduling rates. When this was
done, we started identifying objects for each thread. Now there are only
a few objects that will be called from diffent threads (and we know
exactly which ones these are!). Most exchange of data is beeing done by
simple sending of messages.
Thomas
--
The above E-Mail adress is invalid.
Use thieber at bluewin dot de instead.
Robert C. Martin
Bill Royal wrote in message <3640DB6F...@spicetech.com>...
>We're having some internal debate at my company regarding development of
>multithreaded object modeling.We have a specific question that I'd like
>to see some discussion on from others with experience doing this sort of
>thing in OO systems. When developing an analysis/design model for a
>real-time system, using a typical use-case driven, incremental &
>iterative methodology, _should threading and concurrency issues be
>brought up early in the modeling process_? Or are these implementation
>issues that should be addressed at a different phase later in the
>process?
They are implementation issues that should be deferred as long is is
practicably possible. (And that is usually quite long). Threads are
abstractions of schedule, not abstractions of function. Objects are
abstractions of function. They are orthogonal concepts.
At the high level, you can assume that all (or certain) messages between
objects are asynchronous. That is, they return immediately, but also
continue executing in a seperate thread. But you do not have to identify
the threads, or allocate objects to threads, until much later.
>One school of thought essentially leads to a model in which each thread
>definea a "partition" in which an object or group of objects live --
>there is a concept of "ownership" involved between a thread and its
>associated objects. A thread of execution running through one of its
>objects is unable to invoke methods on another thread's object, mainly
>because it shouldn't have a reference to it in this model (although
>nothing technical limits from having one). For inter-thread
>communication between objects, some other mechanism would be used (named
>pipes, signals, sockets, semaphores, etc. - mechanisms typically
>provided by the platform or OS).
This confuses the concept of thread with the concept of 'subsystem' or
'module'. A thread is *nothing* but an abstraction of schedule. It has no
functional importance. Certain functions operate within certain schedules,
and those functions will then be allocated to the appropriate threads.
Indeed, the various methods of an object may be allocated to different
schedules, and therefore execute in different threads. A thread will
execute within many different objects, and each object may execute within
many different threads.
When heavyweight processes are used, the threads are necessarily separated
by memory protection boundaries. This will force objects to be allocated to
processes simply because the processes own the data segments that hold the
objects. But still the objects can communicate with each other by sending
messages (probably through an ORB or DCOM or RMI).
>
>Another school of thought suggests that threads are mapped based on
>logical flows of control through the system, and these flows have no
>(direct) correlation to groups of classes or their instances. During
>analysis and design, classes are defined with their attributes and
>methods, their relationships are established, and an object model
>showing static and dynamic views of the system is developed. Threads
>are identified later, during the implementation phase. Each thread is
>"flowed" through the design model (each of which would become a sequence
>diagram in UML), adding necessary attributes and/or methods to each
>class in the model to support the thread. Concurrency, synchronization,
>and thread-safety issues must be addressed at this stage, so that, for
>instance, an object's properties could be locked with mutexes as
>necessary or another blocked thread could be made ready to run by the
>scheduler. If the RTOS (or other OS) supports thread priorities, this
>must also be addressed during the implementation phase.
This is closer to what I like; but even this states the realtionship between
logic and thread too strongly. I would not draw sequence diagrams for a
single thread. Rather I would draw sequence diagrams for a logical flow
that crosses many threads. I would keep the logic flow, and the schedule,
completely orthogonal.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
Tim Ottinger
> When developing an analysis/design model for a
> real-time system, using a typical use-case driven, incremental &
> iterative methodology, _should threading and concurrency issues be
> brought up early in the modeling process_?
Boundaries, boundaries, boundaries. How can we bound the problem?
Here:
If you have timing requirements, then they're requirements. They
need to be enumerated early on. But once enumerated they can
wait for a little while. Remember that not all requirements are
invariable, too. If you get a faster platform version in the
future, or if you get a different hardware device in the
future, it can affect things in a big way. Plan to hide the
threading behind interfaces so that it can be changed as
necessary in the future.
In other words, don't build a threading system that controls
something. Build a control system that uses threading.
You should have it worked out just *what* the (sub)system must
accomplished before you start to consider threading and the like.
This is an analysis issue. After you figure out what it has to
do, then you can start to consider whether threads are necessary,
how many, and for what reasons. Do no more threading than is
necessary and no less. Justify each thread.
You should have your scheduling, threading, reentrancy and mutex
strategies worked out for the current increment before coding the
current increment. Adding multithreading after you have an
otherwise workable system is a bit of a pain in the butt. Like
const-correctness and exceptions, adding them late is rather a
mistake.
> So, what are your thoughts? Which way is "more" OO? Which is better
> for robust, real-time system development?
My thoughts were given. Hope they were either interesting or useful.
Which is "more OO"? I'm not sure exactly what that means. But I'd
go with whatever gives the best fit to requirements with the best
maintainability and flexibility.
In the latter case, it depends more upon how well you do your design
than anything else.
--
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Jocelyn Coulmance
Robert C. Martin a écrit dans le message <71tk02$h2f$3...@hirame.wwa.com>...
>>logical flows of control through the system, and these flows have no
>>(direct) correlation to groups of classes or their instances. During
>>analysis and design, classes are defined with their attributes and
>>methods, their relationships are established, and an object model
>>showing static and dynamic views of the system is developed. Threads
>>are identified later, during the implementation phase. Each thread is
>>"flowed" through the design model (each of which would become a sequence
>>diagram in UML), adding necessary attributes and/or methods to each
>>class in the model to support the thread. Concurrency, synchronization,
>>and thread-safety issues must be addressed at this stage, so that, for
>>instance, an object's properties could be locked with mutexes as
>>necessary or another blocked thread could be made ready to run by the
>>scheduler. If the RTOS (or other OS) supports thread priorities, this
>>must also be addressed during the implementation phase.
>
>This is closer to what I like; but even this states the realtionship
between
>logic and thread too strongly. I would not draw sequence diagrams for a
>single thread. Rather I would draw sequence diagrams for a logical flow
>that crosses many threads. I would keep the logic flow, and the schedule,
>completely orthogonal.
>
OOSC2 deals with this issue but I do not have my copy right here. Can
someone confirm or infirm this ?
Regards
Jocelyn
Alec Cawley
<rma...@oma.com> writes
>>multithreaded object modeling.We have a specific question that I'd like
>>to see some discussion on from others with experience doing this sort of
>>real-time system, using a typical use-case driven, incremental &
>>iterative methodology, _should threading and concurrency issues be
>>issues that should be addressed at a different phase later in the
>>process?
>
>They are implementation issues that should be deferred as long is is
>practicably possible. (And that is usually quite long). Threads are
>abstractions of schedule, not abstractions of function. Objects are
>abstractions of function. They are orthogonal concepts.
The problem here is that we do not yet have any OO implementation of
threading. All implementations of threading of which I am aware are
either pre-structured programming (threads can waggle semaphores or send
messages with no limitations other than the designers common sense), or
structured programming level (monitors with balanced entry/exit, but no
restriction on who may do what and when).
In such systems, there is a many-to-many relationship between threads
and objects: one thread may invoke many Objects, one Object may be
visited by many threads. In this light, the designer has no alternative
but to regard threading, as you put it, as an abstraction of schedule,
simply because there is no clean way of "objectivising" the concept of a
thread.
In my opinion, in an OO threading system, the thread concept should be
focussed onto the Object. Threads should not, as they do in all current
systems, wander casually through Objects at large. Instead, the ability
to act asynchronously is an attribute of an Object. If you are modelling
real-world objects, it is surely obvious that some Objects have a life
of their own, and can act asynchronously, while others are passive and
act only when an active Object acts upon them. The same is true of
purely computer-internal Objects; some are daemons with a life of their
own, whilst others are passive (albeit interlocked) data structures upon
which daemons may operate.
I refer to such asynchronous objects as Active Objects, or Actors. A
thread is entirely confined to an Actor, which (IMO) is a "black box".
The terminology of "sending a message" to an Object is literally true in
the case of Actors - one Actor must send an asynchronous message to
another Actor to invoke a method, and receive an asynchronous reply.
Inside each Actor, there will be the usual paraphernalia of passive
Objects, invoked in a single threaded manner by the Actor thread, but
*invisible to other Actors*.
In such an environment, the question posed by the initial poster is
trivially easy to answer (or at least, as trivial as any design
decision). Can your Object act asynchronously? If so, it is an Actor
and, implicitly, has its own thread. If not, there is no thread to worry
about and no question to answer.
--
Alec Cawley
emilr
I agree strongly with my understanding of Alec's view.
I would go further, and argue that if one is developing a multithreaded
application, particularly an embedded application, threading and
and interthread/process communication should be a first class concern.
I.e. part of the analysis process is to identify those operations/functions
in the system that are "actors."
These actors should map onto threads and its methods
should map onto interthread communication primitives.
These should be those objects that have a life-time that encompasses
much or a significant part of the life-time of the application.
This is a guideline, there may be other needs for threads, and some
objects map require several or many threads.
These actors may be more commonly thought of as a servers
in common OS lingo. I usually try to identify those services/objects
that a system requires, and then I encapsulate them in an interface
where all or most methods simply deliver the call parameters
as a "passive" object to the "active" object -- which the active object/server
can then execute.
These servers/actors can, I believe, best be identified by thinking about
the application domain rather than thinking about the specifics of
the application. The question I ask myself when designing a system
is "what would an OS dedicated to this application domain look
like?" OS, here, that set of code/inferstructure that allows one
to express this application "naturally."
In this model a system has four kinds of classes: threads, communication
objects, objects that require synchronization, and "ordinary" objects
which cannot have certain attributes of the others.
What this buys one is what I claim is a "natural" division of threads
and function that minimizes (but does not eliminate) concurrancy problems.
Furthermore, I believe that the other approach leads to overly complex
code that needs to rely heavily on exclusion primitives. I believe
that certain kinds of client/server applications (e.g. data base access)
need this other approach for performance.
Alec Cawley wrote:
Emil Rojas
Lapel Software, Inc.
em...@lapel.com
Patrick Logan
: In my opinion, in an OO threading system, the thread concept should be
: focussed onto the Object. Threads should not, as they do in all current
: systems, wander casually through Objects at large. Instead, the ability
: to act asynchronously is an attribute of an Object. If you are modelling
: real-world objects, it is surely obvious that some Objects have a life
: of their own, and can act asynchronously, while others are passive and
: act only when an active Object acts upon them. The same is true of
: purely computer-internal Objects; some are daemons with a life of their
: own, whilst others are passive (albeit interlocked) data structures upon
: which daemons may operate.
This is trivially the case with Java where Thread is an Object, and so
an "active object" according to your definition. I don't see how you
can keep active objects from "wandering through" non-active objects,
though. Do you propose that non-active objects get assigned to one and
only one active object? Otherwise I don't see much difference between
your descriptions and the other descriptions in this discussion.
Alec Cawley
<plo...@user1.teleport.com> writes
Exactly so. Passive Objects should be entirely contained within Active
Objects, so that there is no thread-ambiguity about accessing them. I
have been developing a large system designed on this basis for several
years now. I have found that this discipline brings the same kind of
order to threading issues that OO brings to data access issues.
The concept does require a very lightweight thread switch. My system is
based on inmos transputers, which have about the lightest weight thread
switch available. However, thread switching in such an environment takes
place only at compiler-known points (method calls of Actors), so that a
friendly compiler can be induced to lighten the context and reduce the
cost of a thread switch.
I have written up some of my thoughts on this subject at
http:://www.cawley.demon.co.uk/cdo.html.
I also received an email this morning from someone who had seen this
page, and pointed me to some related work at
http://ltiwww.epfl.ch
which, while not achieving the containment I advocate for passive
objects, provides a C++ implementation of Active Objects which seems, at
first glance, somewhat better than the Java version. The discipline of
containment can, of course, be self-imposed.
--
Alec Cawley
Alec Cawley
writes
>
>I agree strongly with my understanding of Alec's view.
Thank you.
>I would go further, and argue that if one is developing a multithreaded
>application, particularly an embedded application, threading and
>and interthread/process communication should be a first class concern.
>I.e. part of the analysis process is to identify those operations/functions
>in the system that are "actors."
>
>These actors should map onto threads and its methods
>should map onto interthread communication primitives.
>These should be those objects that have a life-time that encompasses
>much or a significant part of the life-time of the application.
>This is a guideline, there may be other needs for threads, and some
>objects map require several or many threads.
This is, as you understand, my intention. It is my experience that it is
possible to keep a one-to-one relationship between Threads and Active
Objects.
>
>These actors may be more commonly thought of as a servers
>in common OS lingo. I usually try to identify those services/objects
>that a system requires, and then I encapsulate them in an interface
>where all or most methods simply deliver the call parameters
>as a "passive" object to the "active" object -- which the active object/server
>can then execute.
The reason I do not use the term Server is because my experience with
such a scenario is that the system becomes a multi-level Client/Server
system, with every Object acting as a Client to higher level Objects
while sending messages to lower level Objects acting in the Server mode.
Thus every Actor is both Client and Server except for the lowest level
(Server only) and the highest (Client only).
>In this model a system has four kinds of classes: threads, communication
>objects, objects that require synchronization, and "ordinary" objects
>which cannot have certain attributes of the others.
I see a need only for two classed of object - Active Objects (which
encapsulate threads) and Passive Objects, which don't. All Passive
Objects are encapsulated inside Active Objects, except when they are
being passed as message parameters from one Active Object to another.
>What this buys one is what I claim is a "natural" division of threads
>and function that minimizes (but does not eliminate) concurrancy problems.
Agreed.
>Furthermore, I believe that the other approach leads to overly complex
>code that needs to rely heavily on exclusion primitives. I believe
>that certain kinds of client/server applications (e.g. data base access)
>need this other approach for performance.
I do not believe that there is a serious performance overhead if the
system is optimised throughout for this sort of threading. There will be
a considerable cost if such a system is layered on top of an existing
system based on a different paradigm.
--
Alec Cawley
http://www.cawley.demon.co.uk - which contains a discussion of relevance to this
thread.
Patrick Logan
: >This is trivially the case with Java where Thread is an Object, and so
These are interesting ideas. I will read further. Thanks.
One thing that's interesting to me is that they fit in with a couple
of other interesting ideas...
(1) The Erlang concurrent programming language. Erlang supports
multiple concurrent "processes" and passing messages by value
between them. They are "shared nothing" essentially. An Erlang
process may be in the same OS process, a different OS process on
the same host, or a different host. The Erlang program cannot
distinguish them. Erlang has been used to build several 100K+ line
telecommunications programs.
(2) Functional programming languages. Since data is immutable in a
pure FP, there is in essence no sharing between concurrent
threads. (Actually the system is free to share because there is no
*detection* of sharing in a concurrent functional program.)
Erlang, BTW, *is* a functional programming language, and so
concurrent Erlang "processes" in the same thread may share
messages but messages are immutable so they cannot tell if they
are sharing.
Robert C. Martin
Jocelyn Coulmance wrote in message <71ufuk$2hj$1...@news.teaser.fr>...
>>This is closer to what I like; but even this states the realtionship
>between
>>logic and thread too strongly. I would not draw sequence diagrams for a
>>single thread. Rather I would draw sequence diagrams for a logical flow
>>that crosses many threads. I would keep the logic flow, and the schedule,
>>completely orthogonal.
>>
>Is there not a clash with inheritance in this case ? I think B. Meyer's
>OOSC2 deals with this issue but I do not have my copy right here. Can
>someone confirm or infirm this ?
>
I can tell you, from experience, that there is no clash with inheritance.
For an excellent description of threads vs OOD, see Doug Lea's "Concurrent
Programming in Java". (You will find the listing at
http://www.oma.com/Publications/Bibliography ). This book deals with
concurrency, threads, inheritance, objects, etc. Don't be overly concerned
about the fact that Java is in the title. Even though the book does show
Java code; and is an exposition of Java syntax for threads, it is also a
very good book for just general threading/OO principle.
Robert C. Martin
Alec Cawley wrote in message ...
>In my opinion, in an OO threading system, the thread concept should be
>focussed onto the Object. Threads should not, as they do in all current
>systems, wander casually through Objects at large. Instead, the ability
>to act asynchronously is an attribute of an Object. If you are modelling
>real-world objects, it is surely obvious that some Objects have a life
>of their own, and can act asynchronously, while others are passive and
>act only when an active Object acts upon them. The same is true of
>purely computer-internal Objects; some are daemons with a life of their
>own, whilst others are passive (albeit interlocked) data structures upon
>which daemons may operate.
The problem is that a thread does not have "a life of its own". What it
does have is a priority; i.e. a schedule. Most objects that "have a life of
their own" need to perform their functions with more than one priority or
schedule. Some have things to do that are relatively low in priority, and
other things that must be done at a high priority. Thus, a thread, with its
single priority, is not a good basis for an object that "has a life of its
own."
I have worked on multi threaded systems in which objects had single embedded
threads. And I can tell you that they caused significant problems when the
data within the object had to be manipulated according to more than one
schedule.
Consider an object that represents something as simple as a ring buffer. It
has an Add method, and a Remove method.
We have a high priority process that acquires characters from an
asynchronous source. The process must react very quickly when a character
is ready, otherwise the character will be lost. The process grabs the
character and places it in the ring buffer. Another process runs at a
relatively low priority. Whenever nothing more important is running it goes
to the ring buffer and extracts all the characters from it, and then
processes them..
This ring buffer object has two different schedules that execute within it.
The Add function is called from a high priority thread, and the Remove
method is called from a low priority thread. Thus, the object has more than
one thread coursing through it. Moverover, there is no thread that is bound
to the ring buffer.
>I refer to such asynchronous objects as Active Objects, or Actors.
Take a look at Doug Schmidt's "Active Object" paper in
http://www.cs.wustl.edu/~schmidt. UML describes an active object as an
object that sits at the head of a thread. This is an object that has the
controls for the thread itself. i.e. controls like SetPriority, Suspend,
Kill, etc. In that sense, a thread is an object. But UML also specifies
that threads execute in many different objects.
>A
>thread is entirely confined to an Actor, which (IMO) is a "black box".
>The terminology of "sending a message" to an Object is literally true in
>the case of Actors - one Actor must send an asynchronous message to
>another Actor to invoke a method, and receive an asynchronous reply.
>Inside each Actor, there will be the usual paraphernalia of passive
>Objects, invoked in a single threaded manner by the Actor thread, but
>*invisible to other Actors*.
You'll like Doug Schmidt's paper then. It tells you how to do this while
allowing the messages to be regular old method invocations.
>
>In such an environment, the question posed by the initial poster is
>trivially easy to answer (or at least, as trivial as any design
>decision). Can your Object act asynchronously? If so, it is an Actor
>and, implicitly, has its own thread. If not, there is no thread to worry
>about and no question to answer.
Here is a simple object that can act on its own:
class Thread
{
public:
virtual void Poll() = 0;
};
Any class derived from this class has the capability to act asychronously.
If we create many such objects, we can put them into a vector<Thread*>.
Then we can have write the following:
vector<Thread*> threadList;
main()
{
// create all derivatives of Thread and put them into the vector.
vector<Thread*>::iterator i;
for (i=threadList.begin(); i != threadList.end(); i++)
(*i)->Poll();
Alec Cawley
<rma...@oma.com> writes
>
In my opinion, such an object shows asynchronous behaviour and is
therefore itself (another) Active Object with its own thread within it.
It falls out from the design requirement that it must block the high
priority input side, and hence must run at the same, or higher,
priority. Notice how this elegantly encapsulates the raising of priority
of the low priority output side while accessing the buffer, which is
necessary if it is not to block the input task.
I would postulate that *all* the problems you outline would be solved by
making the appropriate objects Active. Many such objects will be,
effectively, database objects which loop forever accepting requests for
information or deposits of data, while having no internal operation of
their own. (Or, a nice pattern, of having the internal operation of
saving themselves to disk, invisibly to their users.)
You may object that this doubles the number of thread switches. If
layered onto a traditional system, this would represent an unpleasant
overhead. However, in my experience most such objects have a thread
which consists of "initialisation; while (true) accept <messages> ;".
They therefore have no context to be saved at the time they execute the
accept operation, and a friendly compiler could be persuaded to take
judicial notice of that fact. This would reduce obviate the need for
saving/restoring registers at a method call. The only things which would
have to be switched would be the "this" pointer (which has to be done at
all method calls) and the stack pointer (a single register).
As a real-time designer (and disregarding OO considerations for the
moment), one thing I find lacking in most scheduling systems is the
multi-way wait operation. Real-time systems have always been event
driven, but this pattern is now spreading into non-real-time; most
windowing programs are event driven. And yet it is difficult to wait for
multiple events (e.g. next click or disk transfer complete or incoming
IP message or incoming inter-task message). Most systems force the user
to shoehorn incoming messages into a single incoming event queue, thus
"de-objectising" the inputs, and then extract them and re-objectise them
upon receipt, without the ability to hold of messages currently
unacceptable, nor to prioritise them. It seems to me that an OO based
protocol allows this to be achieved, and encapsulated, in the standard
OO paradigm.
--
Alec Cawley
Bo Sanden
You can identify problem-domain threads based on whether certain events can
be arranged sequentially, or whether they sometimes happen at the same time.
This tends to lead to a relatively small number of threads, or at least, a
small number of different types of threads. The purpose of each thread
should be clear to everyone involved, developers, maintainers, etc. Too many
threads can lead to a hard-to-understand system and various strange
deadlocks.
There are lots of traditional examples of this kind of threads: User
processes in interactive systems, one thread per caller in a customer
interaction system, one thread per teller in a bank system, etc.
There are also a few "patterns": If there is resource sharing in the
problem, the resources users should be represented as threads, or, if
essentially one resource is used at a time, resource-threads can be arranged
in an assembly-line fashion.
I think each thread should "start" in some object, or even live in it, but
be allowed to operate on other objects. The easiest form of communication
between threads is asynchronously via shared (synchronized) objects that are
operated on by different threads.
There is more about this in a paper in the September/October 1997 issue of
IEEE Software (p 93-100) and in various references on my web page.
Bo Sanden
Colorado Tech
www.pcisys.net/bsanden
Bo Sanden
Jocelyn Coulmance wrote:
> Is there not a clash with inheritance in this case ? I think B. Meyer's
> OOSC2 deals with this issue but I do not have my copy right here. Can
> someone confirm or infirm this ?
What you may have in mind is the so-called inheritance anomaly. It has to do
with synchronized (shared) objects in a class hierarchy. Sometimes, a method
in one class, X, has a condition such as in "while (!condition) wait ( )" in
Java. This means that a thread can only execute the method if the condition is
true and is sometimes referred to as condition synchronization as opposed to
exclusion synchronization, which means that two methods cannot be executed at
the same time.
In a subclass of X may add methods with other conditions. The problem is that
often either the conditions or the methods in the superclass X are affected.
There is no elegant way of solving this other than redefining the original
methods also, thereby defeating much of the purpose of subclassing.
The classic example is a queue with a get method that retrieves the oldest item
in the queue and a put method that puts a new item into the queue. The
conditions are that get may be called when the queue is not empty and put can
be called when it is not full.
Suppose a subclass adds the somewhat silly method getx that cannot be called
immediately after get or getx. (There must be an intervening put.) Now you must
modify get and put to manage a flag that getx's condition can test. There are
more reasonable examples that I cannot think of right now. One involves a
subclass that introduces lock and unlock methods. The conditions of put and get
must then test for the lock status.
Reference: Matsuoka and Yonezawa, "Analysis of inheritance anomaly in
object-oriented concurrent programming languages" in "Research directions in
concurrent OO programming" (Agha, Wegner, Yonezawa, Eds.) MIT Press 1993, p
107-150
Gerhard Menzl
> I would go further, and argue that if one is developing a multithreaded
> application, particularly an embedded application, threading and
> and interthread/process communication should be a first class concern.
> I.e. part of the analysis process is to identify those operations/functions
> in the system that are "actors."
>
> These actors should map onto threads and its methods
> should map onto interthread communication primitives.
> These should be those objects that have a life-time that encompasses
> much or a significant part of the life-time of the application.
> This is a guideline, there may be other needs for threads, and some
> objects map require several or many threads.
I think you are mixing up two very different constructs here: threads, which are
lOS scheduling entities, and active objects, which are application software
modules that promise a certain behaviour. In my experience, treating these two as
equivalent is very dangerous because it ties a high-level concept to a low-level,
platform-specific one.
When designing a multithreaded OO system, I am primarily interested in the
responsiveness of the system. I want to know whether an object responds
synchronously (i.e. whether invoking a method will cause the client to block) or
asynchronously (i.e. the client can continue processing and will be notified of
the result later). I don't care whether this is achieved by the object running a
thread of its own, or two threads, or none, as long as it fulfills the contract.
Threads differ wildly between platforms (as does the terminology). Some operating
systems offer genuine time slicing, others will preempt threads only at certain
points (in the course of a system call, or certain system calls, for example),
some distinguish between threads and processes, and some don't offer
mutlithreading at all. By mapping actors directly to threads you lose all chances
of portability.
For this and other reasons, it is impossible to tell beforehand what the best
concurrency strategy is. Depending on the nature of the application and the
underlying platform, using a thread per client request, a thread pool, or no
multithreading at all, might yield optimal performance. If experimenting with
several strategies requires you to revamp your class design completely every time,
then the entire effort of object-orientation design was for nothing.
Encapsulating multithreading is certainly not an easy task, and you have to go to
great lengths to achieve complete platform independence. However, this does not
mean that one should throw all encapsulation concerns overboard and introduce
strong coupling between high-level application and low-level OS concepts.
Overall concurrency issues should be addressed early in a project, I think, but
implementation details should be deferred.
Gerhard Menzl
Tim Ottinger
>[heavily clipped -- please don't overquote]
> As a real-time designer (and disregarding OO considerations for the
> moment), one thing I find lacking in most scheduling systems is the
> multi-way wait operation.
Then you'll certainly like Doug Schmidt's work on
Reactor and it's variants.
Alex V.
>
> We're having some internal debate at my company regarding development of
> multithreaded object modeling.We have a specific question that I'd like
> to see some discussion on from others with experience doing this sort of
> thing in OO systems. When developing an analysis/design model for a
> real-time system, using a typical use-case driven, incremental &
> iterative methodology, _should threading and concurrency issues be
> brought up early in the modeling process_? Or are these implementation
> issues that should be addressed at a different phase later in the
> process?
>
> definea a "partition" in which an object or group of objects live --
> there is a concept of "ownership" involved between a thread and its
> associated objects. A thread of execution running through one of its
> objects is unable to invoke methods on another thread's object, mainly
> because it shouldn't have a reference to it in this model (although
> nothing technical limits from having one). For inter-thread
> communication between objects, some other mechanism would be used (named
> pipes, signals, sockets, semaphores, etc. - mechanisms typically
> provided by the platform or OS).
>
> logical flows of control through the system, and these flows have no
> (direct) correlation to groups of classes or their instances. During
> analysis and design, classes are defined with their attributes and
> methods, their relationships are established, and an object model
> showing static and dynamic views of the system is developed. Threads
> are identified later, during the implementation phase. Each thread is
> "flowed" through the design model (each of which would become a sequence
> diagram in UML), adding necessary attributes and/or methods to each
> class in the model to support the thread. Concurrency, synchronization,
> and thread-safety issues must be addressed at this stage, so that, for
> instance, an object's properties could be locked with mutexes as
> necessary or another blocked thread could be made ready to run by the
> scheduler. If the RTOS (or other OS) supports thread priorities, this
> must also be addressed during the implementation phase.
>
> they think is best (although feel free to share if you'd like). But I
> would like to see what's worked and what didn't work in other places and
> on other systems.
Concurrency is by no means "an implementation detail" ! It should be
considered at least on an architectural level. According to some more
formal analysis techniques it should be considered during the
REQUIREMENTS stage, as part of the scenarios definition.
I think the second school is more to the point, since the OO models
the real world, which is inherently concurrent (and this concurrency
can surface even in the problem statement, when no classes are defined
yet).
A good book on a subject is "Real Time UML" by Bruce P. Douglass from
Addison Wesley publishing. It deals with the UML application to modeling
a real-time problems and explicitly addresses the concurrency issues.
Hope it helps some.
Regards.
Alex V.
Tom Parke
"Alex V." <Alex_Ve...@icomverse.com> wrote:
>Bill Royal wrote:
>>
>> We're having some internal debate at my company regarding development of
>> multithreaded object modeling.We have a specific question that I'd like
>> to see some discussion on from others with experience doing this sort of
>> thing in OO systems. When developing an analysis/design model for a
>> real-time system, using a typical use-case driven, incremental &
>> iterative methodology, _should threading and concurrency issues be
>> brought up early in the modeling process_? Or are these implementation
>> issues that should be addressed at a different phase later in the
>> process?
>>
>> One school of thought essentially leads to a model in which each thread
>> definea a "partition" in which an object or group of objects live --
>> there is a concept of "ownership" involved between a thread and its
>> associated objects. A thread of execution running through one of its
>> objects is unable to invoke methods on another thread's object, mainly
>> because it shouldn't have a reference to it in this model (although
>> nothing technical limits from having one). For inter-thread
>> communication between objects, some other mechanism would be used (named
>> pipes, signals, sockets, semaphores, etc. - mechanisms typically
>> provided by the platform or OS).
I have to vote for this school. Reasons:
1. Threads and inter-thread communications are more expensive than objects and
procedure calls so threads are naturally "larger" than objects. The cost of
decomposing something into threads is higher than the cost of decomposing
something into objects - so its likely to stop "at a higher level".
2. Threads are introduced into a design for a few clear reasons. Off the top
of my head these are:
a. to handle external events - e.g. comms link, network link, external
hardware, timer initiated processing,
b. to separate tasks of different priority,
c. to encapsulate the system state,
d. to interleave processing with external access - e.g. the thread
pool of server threads for servicing database requests
It is therefore usually possible to arrive at the thread and interthread
architecture before having a detailed desgin.
3. Threads and inter-thread communications have potential deadlock and race
condition bugs that are orders of magnitude harder to analyse and fix than a
sequential ones - so the thread and inter-thread architecture should be as
simple, well understood and as robust as you can make it.
4. OO design methods have not in the past supported concurrency very well. The
idea that I should show in a design, a synchronous communication in the same
way an asynchronous one is an anathema to me. It goes against point 2. above.
5. Note that inter-thread communication can also be via shared objects that
use critical regions or mutual exclusion semaphores to serialise access.
>> Another school of thought suggests that threads are mapped based on
>> logical flows of control through the system, and these flows have no
>> (direct) correlation to groups of classes or their instances. During
>> analysis and design, classes are defined with their attributes and
>> methods, their relationships are established, and an object model
>> showing static and dynamic views of the system is developed. Threads
>> are identified later, during the implementation phase. Each thread is
>>
This approach is well described in "the Octopus book" "Object Orientated
Technology for real Time Systems", Maher Awad et al. Prentice Hall. Looks
risky to me - expensive to do when one has lots of classes, possibly
sensitive to changes (i.e. next iteration and you find the decomposition into
threads is completely different).
>Concurrency is by no means "an implementation detail" ! It should be
>considered at least on an architectural level. According to some more
Absolutely.
>formal analysis techniques it should be considered during the
>REQUIREMENTS stage, as part of the scenarios definition.
As I understand requirements stages (of which there are two - user
requirements and software requirements - a.k.a. specification) concurrency
design is absolutely not considered at this stage - though one may have a
logical model of the system that bares a passing resemblence to the subsequent
concurrent design, the logical model is purely for grouping the requirements.
>I think the second school is more to the point, since the OO models
>the real world, which is inherently concurrent (and this concurrency
>can surface even in the problem statement, when no classes are defined
>yet).
A couple of predjudices here - OO doesn't model anything its just a
framework for us to express models. We can model the real world (analysis)
or our proposed solution (design) and if we do both, because the notations the
same, we can import a lot of analysis into our design. But don't confuse the
two, as Martin Fowler points out in "UML Distilled", excellent book, the
diagrams have different semantics depending on whether one is doing analysis
or design.
The "normal" OO methodology seems to either ignore concurrency or claims all
objects are concurrent and then ignores the implications that has for inter
object communications. So it doesn't model the concurrency in the real world
very well. But as we then design and implement a largely sequential system
that's not a big problem.
Tom Parke
TESSELLA Tom Parke (Tom....@tessella.co.uk)
_/ _/ _/ Tessella Support Services plc
_/ _/ _/ 3 Vineyard Chambers, ABINGDON, OX14 3PX, England
_/ _/ _/ Tel: (44)(0)1235-555511 Fax: (44)(0)1235-553301
Alex V.
>
> In article <365BAE...@icomverse.com>,
> "Alex V." <Alex_Ve...@icomverse.com> wrote:
> >Bill Royal wrote:
[snip]
> >Concurrency is by no means "an implementation detail" ! It should be
> >considered at least on an architectural level. According to some more
> Absolutely.
>
> >formal analysis techniques it should be considered during the
> >REQUIREMENTS stage, as part of the scenarios definition.
> As I understand requirements stages (of which there are two - user
> requirements and software requirements - a.k.a. specification) concurrency
> design is absolutely not considered at this stage - though one may have a
> logical model of the system that bares a passing resemblence to the subsequent
> concurrent design, the logical model is purely for grouping the requirements.
>
> >I think the second school is more to the point, since the OO models
> >the real world, which is inherently concurrent (and this concurrency
> >can surface even in the problem statement, when no classes are defined
> >yet).
> A couple of predjudices here - OO doesn't model anything its just a
> framework for us to express models. We can model the real world (analysis)
{
I agree - I was unclear here. What I meant was that OO methodology was
developed in the first place to narrow the angle between the problem
and solution planes by introducing analysis techniques that would
allow "seamless" mapping of problem entities and relations into the
solution - exactly as you describe below.
Since most of the "real world" real-time problems are "concurrent by
definition" (the system is expected to adress several external events
independantly and meet the deadline for each), I still think that some
evidence of concurrency can be found even during requirements stage.
I agree though, that formal concurrency analysis should be postponed to
the architectural design level.
Alex V.
}
> or our proposed solution (design) and if we do both, because the notations the
> same, we can import a lot of analysis into our design. But don't confuse the
> two, as Martin Fowler points out in "UML Distilled", excellent book, the
> diagrams have different semantics depending on whether one is doing analysis
> or design.
>
> The "normal" OO methodology seems to either ignore concurrency or claims all
> objects are concurrent and then ignores the implications that has for inter
> object communications. So it doesn't model the concurrency in the real world
> very well. But as we then design and implement a largely sequential system
> that's not a big problem.
{
Not totally - some UML variations now include concurrency analysis .
Alex V.
Robert C. Martin
Alex V. wrote in message <36654D...@icomverse.com>...
>I agree - I was unclear here. What I meant was that OO methodology was
>developed in the first place to narrow the angle between the problem
>and solution planes by introducing analysis techniques that would
>allow "seamless" mapping of problem entities and relations into the
>solution
I disagree. IMHO the angle between the problem and solution planes (nice
metaphore ;^) is always pi. I don't believe that OO narrows this angle; I
don't believe that *anything* can narrow this angle. I know that this is a
common concept, and that many people accept it as gospel; but I think that
is more a result of hype than substance.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
TINCC.
Alex V.
Thanks for your response.
Hmm... As I recall, the idea of object (grouping data AND behaviour)
grew out of the concept : That's how REAL-WORLD entities are made, as
stated by Wolfgang Pree in his "Design Patterns for OO software
development" : "...object-oriented - express that these languages
support the modeling of REAL-WORLD building blocks as modules/objects.
As a consequence, the semantic gap between entities in the real world
and their abstraction in a programming system can be reduced." (p. 6).
This statement quite agrees with my own experience. I have recently
participated in a number of big RT software projects. The problems were
complex and the use of OO modeling and analysis techniques enabled us to
map the problem statement entities almost directly into the solution.
We had much less design dilemmas then was expected from previous asses-
ment using conventional top-down analysis techniques.
However this is a matter of opinion. I think that the whole purpose of
newsgroups is the exchange of opinions, even in case that no agreement
is reached, as long as the debate is civil, researched and confined
to the topic (as this one is, and hopefully will continue to be).
Thanks for reading this.
Regards.
Alex V.
Gerhard Menzl
> 1. Threads and inter-thread communications are more expensive than objects and
> procedure calls so threads are naturally "larger" than objects. The cost of
> decomposing something into threads is higher than the cost of decomposing
> something into objects - so its likely to stop "at a higher level".
I disagree. Whether a thread is "larger" than an object depends on nature of the
thread and the nature of the object. A tiny string object on the stack "lives"
inside a thread, so in this case the thread is "larger". On the other hand, if you
have an object whose task it is to monitor a couple of network connections and
inform clients when data arrive, it will be just the other way round: the object
uses a thread internally in order to respond asynchronously to client requests,
therefore the object is "larger" than the thread.
I share Robert C. Martin's view that threads and objects as orthogonal concepts
(the fact that you can model threads as objects notwithstanding). Threads are
essentially a purely procedural, OS-level concept.
> 2. Threads are introduced into a design for a few clear reasons. Off the top
> of my head these are:
> a. to handle external events - e.g. comms link, network link, external
> hardware, timer initiated processing,
> b. to separate tasks of different priority,
> c. to encapsulate the system state,
> d. to interleave processing with external access - e.g. the thread
> pool of server threads for servicing database requests
>
> It is therefore usually possible to arrive at the thread and interthread
> architecture before having a detailed desgin.
But unless you are very familiar with multithreading on a particular system, it is
impossible to tell which division of labour between threads will yield optimal
performance before you actually run the software. Consider the network listener
example. Depending on the number of processors and the operating system, it might
be better to use one single thread for all network connections, or a thread pool,
or one thread per connection. If you hide the threading logic in the listener
object, you can change your strategy, even dynamically at runtime, without
affecting the client code at all.
Threads are a means to achieve asynchronous behaviour and (quasi-)parallel
processing. The way I see it, in an OO system it should be up to class interfaces
to promise behaviour. Whether a request is handled synchronously or asynchronously
is a matter of the contract between an object and its client.
> 4. OO design methods have not in the past supported concurrency very well. The
> idea that I should show in a design, a synchronous communication in the same
> way an asynchronous one is an anathema to me. It goes against point 2. above.
Douglas C. Schmidt has made extensive research into OO modelling of concurrency. I
think that his ADAPTIVE Communication Environment supports concurrency very well
(see http://www.cs.wustl.edu/~schmidt/ACE.html).
I don't think anyone would advocate treating synchronous and asynchronous
communication in the same way. The difference between the two approaches is
whether you communicate (a)synchronously with a low-level thread or a high-level
object.
> 5. Note that inter-thread communication can also be via shared objects that
> use critical regions or mutual exclusion semaphores to serialise access.
There are operating systems that do not support this idiom very well. In order to
keep portable, it is all the more important to hide threading issues behind
appropriate abstractions.
> The "normal" OO methodology seems to either ignore concurrency or claims all
> objects are concurrent and then ignores the implications that has for inter
> object communications. So it doesn't model the concurrency in the real world
> very well. But as we then design and implement a largely sequential system
> that's not a big problem.
What do you consider as the "normal" OO methodology? UML (which is not a
methodology, though) supports activity diagrams.
Gerhard Menzl
Robert C. Martin
Alex V. wrote in message <36669B...@icomverse.com>...
>
>However this is a matter of opinion. I think that the whole purpose of
>newsgroups is the exchange of opinions, even in case that no agreement
>is reached, as long as the debate is civil, researched and confined
>to the topic (as this one is, and hopefully will continue to be).
Well said!
Jack W. Crenshaw
>
> I disagree. IMHO the angle between the problem and solution planes (nice
> metaphore ;^) is always pi. I don't believe that OO narrows this angle; I
> don't believe that *anything* can narrow this angle. I know that this is a
> common concept, and that many people accept it as gospel; but I think that
> is more a result of hype than substance.
>
Jack
Robert C. Martin
Ziv Caspi
> Robert C. Martin wrote:
> >
> > I disagree. IMHO the angle between the problem and solution planes (nice
> > metaphore ;^) is always pi. I don't believe that OO narrows this angle; I
> > don't believe that *anything* can narrow this angle. I know that this is a
> > common concept, and that many people accept it as gospel; but I think that
> > is more a result of hype than substance.
> >
> I certainly hope, Robert, you meant to say, "always pi/2" <grin>
>
Perhaps he meant just that -- the two are going in opposite directions,
never converging in a point ;-)
--------------------------------
Ziv Caspi
zi...@netvision.net.il
Jack W. Crenshaw
> >>
> >> I disagree. IMHO the angle between the problem and solution planes (nice
> >> metaphore ;^) is always pi. I don't believe that OO narrows this angle;
> I
> >> don't believe that *anything* can narrow this angle. I know that this is
> a
> >> common concept, and that many people accept it as gospel; but I think
> that
> >> is more a result of hype than substance.
> >>
> >I certainly hope, Robert, you meant to say, "always pi/2" <grin>
>
>
For the record, I flat-out refuse to accept the term "thread," which
seems to be indistinguishable from a task, in discussions of real-time
systems. There may be some prior use of the term I'm not aware of, but
as nearly as I've been able to determine, the term, "threads," was
introduced by J. Gordon Letwin in his original version of OS/2, which
was about as far removed from a real-time system as it's possible to
get. Also AFAIK, JGL never wrote a real-time system in his _LIFE_, so
I'm not prepared to let him rename the term, "task," for me.
If anyone here can provide more info as to how a task got renamed a
thread, or if there is some distinguishing difference between the two,
I'm ready to be educate. Otherwise, I'm going to remain a reactionary
old curmudgeon and use the original term.
Jack
Larry Brasfield
Jack W. Crenshaw wrote in message <36696F...@magicnet.net>...
[snip]
>For the record, I flat-out refuse to accept the term "thread," which
>seems to be indistinguishable from a task, in discussions of real-time
>systems.
I believe that tasks are only coincidentally one-for-one
with threads, and may not be in many systems. The
words denote distinct concepts in my mind, especially
during design. I suspect the confusion between "task"
and "thread" has arisen because multiple independent
tasks are often effected with separate threads. Some
RTOS vendors have latched onto "task" in technical
documentation to refer to threads in systems where
all threads (potentially) share resources in common,
including the address space. In systems that have no
process separation, that is a harmless confusion as
long as it does not corrupt people's usage and escape
into realms where the distinction matters.
People speak of "multi-tasking" in a very general way,
referring to getting work done concurrently, without
specifically committing to whether processes can
have multiple threads of control or whether the only
task switching is process activation.
>There may be some prior use of the term I'm not aware of, but
>as nearly as I've been able to determine, the term, "threads," was
>introduced by J. Gordon Letwin in his original version of OS/2, which
>was about as far removed from a real-time system as it's possible to
>get. Also AFAIK, JGL never wrote a real-time system in his _LIFE_, so
>I'm not prepared to let him rename the term, "task," for me.
At this point, the terminology has been adopted by so many
people that the issue is not whether Mr. Letwin is going to
rename the concept denoted these days by "thread". Your
ignorance of Mr. Letwin's work history is even less relevant.
I am not ready to accept that he invented the term, either.
You had better get after all the people who mention "thread-
safe" classes. Somehow, I think they are not going to start
saying "task-safe" instead.
>If anyone here can provide more info as to how a task got renamed a
>thread, or if there is some distinguishing difference between the two,
>I'm ready to be educate.
That's a refreshing change from "I flat-out refuse".
I have done real-time programming, long before moving
into the less embedded realm. I had always, (perhaps
naively), associated "task" with "unit of work" and when
I saw the term applied to a combination of instruction
pointer, register state, and stack area, I thought "Ok, it's
a stretch, but tasks are the usual purpose of using one
of these units of execution." I always thought of it as
sloppy, amusing usage, due to its confusion between
means and ends. When I saw "thread" the first time,
I started using it because it better conveys its referent.
I find it easy to visualize execution threading its way
through the instruction store. With a given thread, I
may elect to accomplish several tasks.
>Otherwise, I'm going to remain a reactionary
>old curmudgeon and use the original term.
Just be sure to explain what you mean. Your holdout,
(if that's what it is), is reactionary rather than logical.
Language changes, often for good reason.
--Larry Brasfield
Above opinions may be mine alone.
(Humans may reply at unundered larry_br@sea_net.com )
Don Yuniskis
> For the record, I flat-out refuse to accept the term "thread," which
> seems to be indistinguishable from a task, in discussions of real-time
> systems. There may be some prior use of the term I'm not aware of, but
> as nearly as I've been able to determine, the term, "threads," was
> introduced by J. Gordon Letwin in his original version of OS/2, which
> was about as far removed from a real-time system as it's possible to
> get. Also AFAIK, JGL never wrote a real-time system in his _LIFE_, so
> I'm not prepared to let him rename the term, "task," for me.
Most of this nomenclature is inconsistently used.
I have seen the terms: job, task, process, thread
each applied to what are *in essence* (though not in *detail*)
the same concepts. As such, I either deliberately ignore
the mis(?)use and only concentrate on the consistency of usage
(within a given context).
Add to this the silly notion of "lightweight", etc.
I tend to rely on task and job as descriptive of conceptual
*chores* (blech! now I've added a new noun to the foray).
For example, when crafting the system design, I may describe
a "temperature monitoring task". To me, this is a shorthand
for a set of activities which must be performed to achieve
that desired goal. How it is *implemented* hasn't entered into
the discussion -- yet.
I tend to consider a process as a *passive* entity (!!).
A process is a container that holds threads. Threads
are active entities -- execution streams. Processes are
the environments and assets that they use to perform
their "chores" (i.e. any semaphores they own, the
address space in which they operate, etc.)
A UN*X process, for example, would be one of my processes
with a single thread.
Since many MTOS's don't usually provide separate contexts
for their "tasks" (misusing the word here by my definition),
they tend to fit the single process, multiple thread model
in my terminology (i.e. single address space, "task" A
can often steal "task" B's resources, etc. Yet, *conceptually*,
they are usually some number of tasks (using my conceptual
definition of "chore") each of which requires one or more
"execution units" for the implementation.
> If anyone here can provide more info as to how a task got renamed a
> thread, or if there is some distinguishing difference between the two,
> I'm ready to be educate. Otherwise, I'm going to remain a reactionary
> old curmudgeon and use the original term.
Sorry that my explanation might add still more confusion to the
issue (though I find my definitions quite workable!). If you
think it's bad now, wait until MS "discovers" the concept
and reinvents it -- like every other "original" thing that
they proclaim... :>
-don
Llewellyn Griffiths
Jack W. Crenshaw <jcr...@magicnet.net> wrote in article
<36696F...@magicnet.net>...
In real-time systems there appears to be a one-for-one relationship between
threads and tasks although I get the impression that the term "thread" has
a slightly different meaning to the dialogue box crowd. The last time I
wrote some software for a PC was just after MSDOS 3.3 came out so I can't
really comment about that area.
I think that, at least in the real-time systems area, it is merely trendy
to refer to tasks as threads and the marketing people have grabbed hold of
the term. eg. ThreadX [an excellent RTOS by the way - I am using it in one
of my current projects].
Llew Griffiths
--
LLEWELLYN GRIFFITHS
Llew Griffiths & Associates Pty Limited
Melbourne, Australia
info AT llga DOT com DOT au
The reply address is a black hole for spam
> For the record, I flat-out refuse to accept the term "thread," which
> seems to be indistinguishable from a task, in discussions of real-time
> systems. There may be some prior use of the term I'm not aware of, but
> as nearly as I've been able to determine, the term, "threads," was
> introduced by J. Gordon Letwin in his original version of OS/2, which
> was about as far removed from a real-time system as it's possible to
> get. Also AFAIK, JGL never wrote a real-time system in his _LIFE_, so
> I'm not prepared to let him rename the term, "task," for me.
>
> If anyone here can provide more info as to how a task got renamed a
> thread, or if there is some distinguishing difference between the two,
> I'm ready to be educate. Otherwise, I'm going to remain a reactionary
> old curmudgeon and use the original term.
>
> Jack
>
Manfred Knemeyer
does not seem to be a silly notion. It makes clear the distinction
in resources (address space, etc.) which differ here. Useful, IMHO.
David B Lightstone
There are two parameters which serve to distinguish tasks,
processes, and
threads: (1) Availability of system resources; (2) Effort
required
to perform a context switch.
Threads have minimal effort.
Threads have less restricted access to resources which they share
(i.e. named vs.
anonymous identification)
Much of the confusion between tasks, processes and threads
probably (speculation)
relates to transposing concepts from one context (i.e. operation
system) into their
quasi-equivalent concepts of another context. The context is king
don't forget the
context of the conversation.
Smart marketers make undo effort to create this confusion. In the
programming world
is there really a difference between a routine, subroutine,
function, or method. They
are context dependent terms which should (personal opinion) not
be compared with each
other without considering a context.
Dave Lightstone
Llewellyn Griffiths wrote in message
<01be208e$ffc68e00$0100007f@llga>...
Ell
What you say below is essentially how the concepts are defined for
Windows NT and COM.
>I tend to consider a process as a *passive* entity (!!).
>A process is a container that holds threads. Threads
>are active entities -- execution streams. Processes are
>the environments and assets that they [threads] use to perform
>their "chores" (i.e. any semaphores they own, the
>address space in which they operate, etc.)
Each process has at least a single thread, but may have more.
Processes communicate using Remote Procedure Call (RPC).
The thing to be added in terms of the COM threading model is that each
object is created and resides within in its own apartment. These
apartments have one or more threads. Objects are responsible for
coordinating the multiple threads in their apartment.
Elliott
--
The Craftite conspiracy is:
a) their holding life terms as c.o.m. moderators
b) their oligarchic selection of new c.o.m. moderators
c) their not banning "one ups-manship" as a c.o.m. practice
d) their use of moderator comments in c.o.m.
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
Don Yuniskis
> Don Yuniskis <d...@cutout.gci-net.com> wrote:
> What you say below is essentially how the concepts are defined for
> Windows NT and COM.
Actually, I borrowed the definitions from Mach. It wouldn't
be surprising if NT uses similar -- R. Rashid (Mach's "champion")
later went over to The Evil Empire...
> >I tend to consider a process as a *passive* entity (!!).
> >A process is a container that holds threads. Threads
> >are active entities -- execution streams. Processes are
> >the environments and assets that they [threads] use to perform
> >their "chores" (i.e. any semaphores they own, the
> >address space in which they operate, etc.)
> Each process has at least a single thread, but may have more.
The difference in my definition is that the process is *only*
the container (and, informally refers to all that it contains
in much the same way we talk about a "box of jelly beans", etc.).
The process is still just a *shell*/container and can't do anything
(besides consume *space*)
> Processes communicate using Remote Procedure Call (RPC).
RPC is usually the term applied to *IPC* when the "processes"
reside on different CPU's. Similar to RMI in the C++ world...
Note that, strictly speaking, the *processes* don't communicate
but, rather, one or more threads within a process (container)
communicates with another thread *represented* by a particular
(other) process.
Threads, of course, can communicate among themselves using
semaphores, FIFOs, shared memory, etc. -- since they each
reside in the same "container" and have access to the same
resources.
> The thing to be added in terms of the COM threading model is that each
> object is created and resides within in its own apartment. These
> apartments have one or more threads. Objects are responsible for
> coordinating the multiple threads in their apartment.
Argh! I was hesitant to add the moniker "chore" to the mess...
now we've got *apartments*, etc. :> Who's turn is it to
wash the dishes??
--don
Robert Oliver
>
> If anyone here can provide more info as to how a task got renamed a
> thread, or if there is some distinguishing difference between the two,
> I'm ready to be educate. Otherwise, I'm going to remain a reactionary
> old curmudgeon and use the original term.
As I understand it, both task and thread imply a separate path of
execution
through a program. (ie. separate program counter)
However, task also implies separate address space. The kernal keeps two
tasks from interfering with each other's data.
Two or more threads may execute in the same address space. This
requires
the programmer to manage the concurrency issues.
Context switches using threads should be somewhat faster.
Hope this helps.
Bob Oliver
Tom Sheppard
<d...@cutout.gci-net.com> wrote:
...
>Add to this the silly notion of "lightweight", etc.
I don't find the notion silly, just not as pervasive as it once was.
Probably because the definition is soft [or is it hard? No wait, I mean
firm... ;-) ]
>I tend to rely on task and job as descriptive of conceptual
>*chores*
...
>I tend to consider a process as a *passive* entity (!!).
>A process is a container that holds threads. Threads
>are active entities -- execution streams. Processes are
>the environments and assets that they use to perform
>their "chores" (i.e. any semaphores they own, the
>address space in which they operate, etc.)
My definition is similar to yours. I define task to be the functional
specification of the unit of work which needs to be accomplished. This may
require one or more modules creating one or more processes with each
process consisting of one or more threads (independent flow of control).
The process is a bit more than a container in that it has context itself.
Priority, scheduling policy, address space, name space, permissions, etc.
Threads inherit these attributes but are not constrained to them.
Threads typically cooperate with each other to accomplish the task(s)
although this is not mandatory.
The relationship between tasks and processes can be many to many (where
one to one is just a special case).
I refer to processes when I mean the set of threads as a whole --
especially when you don't need to get down into the details of the
execution flow.
Now this is just my definition. I firmly believe it's much more important
to adopt a standard terminology within your design team. Often, this will
follow the terminology that the RTOS vendor uses. If they use the term
"task" to mean what I call process or threads, so be it. I don't get hung
up on the semantics as long as everyone is using the same dictionary. :-)
...Tom
Sam Roberts
I think of threads as sharing memory and probably other resources with
other threads,
of processes not sharing resources such as memory with other
processes,
and of a task being a generic term, not clearly indicating whether a
task is a thread or a process, and thus usually used by those working
with an O/S or kernel that does NOT support both types of tasks (such
as VxWorks).
Clearly, the terms have not reached a consensus as to their meaning,
funny considering how important the concepts are.
Sam
--
Sam Roberts (s...@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
"News is very popular among its readers." - RFC 977 (NNTP)
Don Yuniskis
> >I tend to consider a process as a *passive* entity (!!).
> >A process is a container that holds threads. Threads
> >are active entities -- execution streams. Processes are
> >the environments and assets that they use to perform
> >their "chores" (i.e. any semaphores they own, the
> >address space in which they operate, etc.)
> My definition is similar to yours. I define task to be the functional
> specification of the unit of work which needs to be accomplished. This may
> require one or more modules creating one or more processes with each
> process consisting of one or more threads (independent flow of control).
> The process is a bit more than a container in that it has context itself.
> Priority, scheduling policy, address space, name space, permissions, etc.
> Threads inherit these attributes but are not constrained to them.
Yes -- though the process itself remains a passive entity. All
it does is take up *space* (so to speak). I.e. the threads within the
process (container) are actually the only execution/active units.
The distinction between the group of threads collectively known
as "process 1" and those collectively known as "process N" is
based entirely on the environments (containers) in which those
threads exist/operate.
> Threads typically cooperate with each other to accomplish the task(s)
> although this is not mandatory.
Agreed. A common approach for a multithread "process" is that of
a multithreaded server -- consider a service that is relatively
expensive (in terms of latency, resources, etc.) to implement.
Better performance (i.e. *service*) can usually be obtained by
creating several threads (number is chosen based on expected
load for that service -- i.e. number of concurrent connections -- and
resources you want to set aside for them, etc.) and having each
thread sit and wait on the service port for a request. As
requests arrive, the next free thread can accept the request and
begin to process it.
Note that in this type of C-S implementation, the designer can
take advantage of the multithreaded nature of the service and
allow each serving thread to assume the priority of the requesting
client "task". So, the service can benefit from the same
priority schemes that the system as a whole adopts (server
bottlenecks being an overlooked case where priority inversion can creep
into a design that otherwise was free of this problem)
> The relationship between tasks and processes can be many to many (where
> one to one is just a special case).
Yes -- assuming "task" to be the equivalent of my "chore"...
> I refer to processes when I mean the set of threads as a whole --
> especially when you don't need to get down into the details of the
> execution flow.
> Now this is just my definition. I firmly believe it's much more important
> to adopt a standard terminology within your design team. Often, this will
Exactly. Quibbling over semantics is just an attempt to better
define a particular set of terminology which, ultimately, has
to be *applied*. Hence, it's often easier when *informally*
discussing these concepts to resort to bogus terms *outside*
the norm -- e.g., "chore".
> follow the terminology that the RTOS vendor uses. If they use the term
> "task" to mean what I call process or threads, so be it. I don't get hung
> up on the semantics as long as everyone is using the same dictionary. :-)
--don
Jack W. Crenshaw
>
> I believe that tasks are only coincidentally one-for-one
> with threads, and may not be in many systems. The
> words denote distinct concepts in my mind, especially
> during design.
Name one.
> Some
> RTOS vendors have latched onto "task" in technical
> documentation to refer to threads in systems where
> all threads (potentially) share resources in common,
> including the address space.
In your experience, does any RTOS vendor use the term "threads"?
> People speak of "multi-tasking" in a very general way,
> referring to getting work done concurrently, without
> specifically committing to whether processes can
> have multiple threads of control or whether the only
> task switching is process activation.
Now you've gone and introduced two _NEW_ term, "process," as well as
"process activation." Both terms come from the world of time-share
systems (e.g., Unix) and really have no place in a discussion of RTOS's.
> Your ignorance of Mr. Letwin's work history is even less relevant.
> I am not ready to accept that he invented the term, either.
I'm pretty sure I gave the caveats, "as nearly as I've been able to
determine" and "AFAIK." Was there anything about these terms that you
failed to understand? In case you missed the point, it was a general,
open invitation to correct me if I got it wrong. If you have further
data to add, such as a prior use of the term, please feel free to post
it. Otherwise, kindly keep your comments re ignorance to yourself.
> You had better get after all the people who mention "thread-
> safe" classes. Somehow, I think they are not going to start
> saying "task-safe" instead.
It is not my fault if a new generation comes along every once in awhile
and re-invents the wheel because they're too lazy to see what's already
been done, or too ignorant to be aware of it. However, inventing new
names for things, simply because one never knew the old one, is not a
very good excuse for adding to the confusion level of the universe.
Way back when Commodore was introducing the Amiga, some illiterate, but
no doubt capable, software engineer labelled the OS kernel the "kernal."
Manuals duly came out, describing the inner workings of the AmigaDos
"kernal," and soon book stores were selling the equivalent of "AmigaDos
Kernal for Dummies."
When some of us who had read a dictionary pointed out the misspelling,
people at Commodore put up a smoke screen of defense, arguing, amongst
other things, that it was not a noun but a proper name. Others argued
that it was an acceptable alternative spelling. AFAIK (again, feel free
to correct me if you know more), Commodore never _DID_ admit it was just
plain bad English. But that was what it was.
Personally, I don't care _HOW_ many of you folks who grew up with
Windows insist on calling a task a thread. Unless and until someone
gives me some meaningful distinction between the two, I think it's
reasonable to ask why you insist on obfuscating the universe by
inventing new names for old things.
Jack
Jack W. Crenshaw
See my response to Don. The term process, like fork/exec, are Unix
terms. While I can understand that folks who are familiar with Unix
might want to make a distinction between a process, which can have only
one copy per user, and a task, which can have more, via forking, none of
these terms fit very well into a discussion of RTOS's. People have been
doing just fine, in the realtime world, with the term, task. I've asked
and asked folks to give me a real distinction between task and thread,
but so far, no one has.
Jack
George Neuner
<larry_br@sea_net.com> wrote:
>
>People speak of "multi-tasking" in a very general way,
>referring to getting work done concurrently, without
>specifically committing to whether processes can
>have multiple threads of control or whether the only
>task switching is process activation.
Yeah! Everyone has completely forgotten that it is technically
impossible to "multi-task" and that it is possible to "multi-process"
only with multiple processors. Context switching on a single
processor was traditionally referred to as "multi-programming".
>
>>There may be some prior use of the term I'm not aware of, but
>>as nearly as I've been able to determine, the term, "threads," was
>>introduced by J. Gordon Letwin in his original version of OS/2,
>
First use I remember was in "Communicating Sequential Processes" by
C.A.R. Hoare back in the 70's. He spoke about using multiple
"threads of control".
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
LSPB
[snip] ...
|People have been doing just fine, in the realtime world, with the term,
task. I've asked
|and asked folks to give me a real distinction between task and thread,
|but so far, no one has.
Ok, I see this has been posted to both comp.object and comp.realtime,
therefore lets pull the two together. We use the following scheme in our
OO-RTOS...
The Thread is an enumerated set of sequential instructions presented to a
CPU. A Thread means something to the RTOS scheduler. The Thread is presented
to the RTOS scheduler as a frozen CPU state.
Even in a "C", or service-based RTOS, the term Task represents the "more
than the sum of the parts." The "more" includes data, collaboration (i.e.
synchronization) and even other Thread interfaces into the Task. Further, a
Task might include other RTOS widgets: Timers, Queues, Mutexes, ...
Although in a service-based RTOS the term Task is further butchered by a
service such as "Create_Task," the programmer doesn't lose sight of the fact
that the Thread created by this service is just one "part" of the Task.
Unfortunately, many programmers call the thread entry point something like
Task1_Entry and use external resources and "associate" these resources as
owned by this function.
The Task has a distinct, collective state which consists of the states of
its associated resources. This is regardless of how these associated,
collaborating resources have been packaged.
This all becomes clearer and is driven home by using objects --> consider
the following Task object example. Here's the money shot: this Task is
entered by more than one Thread!
// An RTOS Task object within a non-protected memory area.
class ThreadBasedRealTimeTask
{
protected:
// Task based state data and other goodies.
int myNiceDataPiece;
MyNiceRTOSMutex mutex; // for arbitration.
// Virtual entry routine is first point of execution that
// is called by RTOS scheduler. This represents "this"
// thread of execution.
virtual
void
Entry()
{
while( true )
{
// Sleep for 10 ms then do a "chore" (I liked that term!)
// this-> used for clarification.
this->Sleep( 10 );
// Synchronize multiple Thread access.
mutex.Obtain();
{
myNiceDataPiece *= 2; // The object's chore.
}
mutex.Release();
}
}
public:
// Constructor creates a thread of execution to run
// under the RTOS scheduler, with the first point of
// execution being the virtual Entry() routine.
ThreadBasedRealTimeTask()
{
// Of course, this is being called from a "different" thread.
myNiceDataPiece = 1;
}
// Member called on different Thread...
void
MemberToBeCalledFromDifferentThread()
{
int temp;
// Synchronize multiple thread access.
mutex.Obtain();
{
temp = myNiceDataPiece;
}
mutex.Release();
return( temp );
}
}
The above would not be classified as a "Process," nor can it be called a
"Thread." Therefore, it must be called a "Task."
Let the nitpicking begin!
-Lance
Larry Brasfield
>Larry Brasfield wrote:
>>
>> I believe that tasks are only coincidentally one-for-one
>> with threads, and may not be in many systems. The
>> words denote distinct concepts in my mind, especially
>> during design.
>
>Name one.
A "cooperatively multi-tasked" system has
multiple tasks but need not have more than
a single thread dedicated to its tasks.
Of course, if we accept your definition whereby
the two words mean exactly the same thing, then
I am unable to name one. My answer presupposes
that you pose a real question here.
When I design a system that will exhibit
concurrency, where logically independent
tasks must be accomplished, I think about
it in terms of "task" or "process" without
any intention of committing, at that early
stage, to effecting those activities with
multiple threads or (shudder) tasks.
>> Some
>> RTOS vendors have latched onto "task" in technical
>> documentation to refer to threads in systems where
>> all threads (potentially) share resources in common,
>> including the address space.
>
>In your experience, does any RTOS vendor use the term "threads"?
Not that I have seen. I am not prepared to say
that RTOS vendors have the final word on usage.
>> People speak of "multi-tasking" in a very general way,
>> referring to getting work done concurrently, without
>> specifically committing to whether processes can
>> have multiple threads of control or whether the only
>> task switching is process activation.
>
>Now you've gone and introduced two _NEW_ term, "process," as well as
>"process activation." Both terms come from the world of time-share
>systems (e.g., Unix) and really have no place in a discussion of RTOS's.
I do not view those worlds as being so disjoint. There
is a continuum between them. I think you are mistaken
if you believe that the concept denoted by "process"
cannot be part of a realtime OS. Given suitable latency
guarantees, an OS that managed separate processes could
still be wholly or partially an RTOS.
My use of "process activation" is no more a new term
here than "process" is. Your objection to new terms
is getting a bit extreme, I think.
>> Your ignorance of Mr. Letwin's work history is even less relevant.
>> I am not ready to accept that he invented the term, either.
>
>I'm pretty sure I gave the caveats, "as nearly as I've been able to
>determine" and "AFAIK." Was there anything about these terms that you
>failed to understand?
No. I read them as statements of limited knowledge.
>In case you missed the point, it was a general,
>open invitation to correct me if I got it wrong.
I did not miss your point. I asserted that it is
irrelevant. Since you seem to still believe it
is relevant, I will explain why it is not.
>If you have further
>data to add, such as a prior use of the term, please feel free to post
>it. Otherwise, kindly keep your comments re ignorance to yourself.
Let's see if I got your point. If Mr. Letwin
invented the term "thread" himself, then you
steadfastly refuse to consider whether it is
a useful term or more useful than "task". But
if he got the term somewhere else, or worked
with an RTOS sometime in his life, you might
be willing to consider it differently. Since
you don't know which case applies, (which is
clearly a position of ignorance), you remain
unsure whether to open your mind to the term.
I suggest, (and only suggest, because I see no
point in persuasion), that the term "threads"
has become popular for the same reasons that
most terms do, and that clarity, comprehension,
and usage are the relevant factors to consider
in this matter. Whether Mr. Letwin invented
the term or merely helped popularize it does
not matter to most of the people who use it.
The origin you suspect is irrelevant.
>> You had better get after all the people who mention "thread-
>> safe" classes. Somehow, I think they are not going to start
>> saying "task-safe" instead.
>
>It is not my fault if a new generation comes along every once in awhile
>and re-invents the wheel because they're too lazy to see what's already
>been done, or too ignorant to be aware of it. However, inventing new
>names for things, simply because one never knew the old one, is not a
>very good excuse for adding to the confusion level of the universe.
As I pointed out before, the term "task" has
been used loosely. Perhaps not in your corner
of the world, where a few vendors have settled
on a consistent usage, but in the larger world.
That fact alone is enough to motivate use of
a word that more precisely conveys the concept
of "thread of control". As I indicated before,
"task" is a sloppy choice of words because it
has ordinary meaning that too closely resembles
the concepts involved when people use threads.
(Commonly, they accomplish ongoing tasks.)
There is no germane issue of "fault" here.
Inventing a word where none is already known
needs no excuse. There are excellent reasons
for people to do that. The fact that another
word from some isolated community might exist
to serve the same purpose provides no excuse
to postpone discussion until a world-wide (or
universal) search can be conducted for it.
Personally, I think if any excuse is due, it
would be for hijacking a term of discourse
whose original, general meaning is useful in
programming. Part of the reason I readily
adopted the term "thread" was because, to me,
using "tasks" to accomplish tasks seems silly.
>Way back when Commodore was introducing the Amiga, some illiterate, but
>no doubt capable, software engineer labelled the OS kernel the "kernal."
>Manuals duly came out, describing the inner workings of the AmigaDos
>"kernal," and soon book stores were selling the equivalent of "AmigaDos
>Kernal for Dummies."
>
>When some of us who had read a dictionary pointed out the misspelling,
>people at Commodore put up a smoke screen of defense, arguing, amongst
>other things, that it was not a noun but a proper name. Others argued
>that it was an acceptable alternative spelling. AFAIK (again, feel free
>to correct me if you know more), Commodore never _DID_ admit it was just
>plain bad English. But that was what it was.
Your story is not analogous. Nobody would
choose "kernal" over "kernel" because they
thought it was clearer. People have adopted
"thread" instead of "task" because the former
term has not been muddied by indiscriminate
use and is not likely to collide with other
useful meaning in the same contexts.
>Personally, I don't care _HOW_ many of you folks who grew up with
>Windows insist on calling a task a thread. Unless and until someone
>gives me some meaningful distinction between the two, I think it's
>reasonable to ask why you insist on obfuscating the universe by
>inventing new names for old things.
If you truly believe that people who use the
term "thread" do so intending to obfuscate,
you are too far off the deep end to reason
with. I see the term in common use by many
folks who are eminently reasonable and who
obviously intend to communicate clearly.
You may lament that the term has become
popular, and rail upon its suspect origin,
but those people, along with most others
who use the term, will use it because they
believe it conveys the meaning they intend.
>Jack
--Larry Brasfield
a.k.a. Obfuscator of the Universe
Chris Gray
> Larry Brasfield wrote:
> >
> > Some
> > RTOS vendors have latched onto "task" in technical
> > documentation to refer to threads in systems where
> > all threads (potentially) share resources in common,
> > including the address space.
>
> In your experience, does any RTOS vendor use the term "threads"?
>
Express Logic use the term in the documentaion for ThreadX (surprise).
In fact, as they explain on page 4 of the User Guide,
To avoid confusion, ThreadX does not use the term _task_.
> Way back when Commodore was introducing the Amiga, some illiterate, but
> no doubt capable, software engineer labelled the OS kernel the "kernal."
Vielleicht.
--
Eur. Ing. Chris Gray MBCS C. Eng. chris...@smartmove.be
Don Yuniskis
> Jack W. Crenshaw wrote in message <366DBE...@magicnet.net>...
> >Larry Brasfield wrote:
> >>
> >> I believe that tasks are only coincidentally one-for-one
> >> with threads, and may not be in many systems. The
> >> words denote distinct concepts in my mind, especially
> >> during design.
> >
> >Name one.
> A "cooperatively multi-tasked" system has
> multiple tasks but need not have more than
> a single thread dedicated to its tasks.
You're further confusing the issue here. Semantically, these are
still different "threads"/"tasks". You analogy is akin to
implementing a package like pthreads and *multiplexing* those
threads onto some *other* number of kernel threads in the
implementation (as if that won't confuse things more! :>)
Would you claim that separate *tasks* running on a preemptive/nonpreemptive
scheduler were really a *single* task because they all share the CPU
(in much the same way that you are having those "co-operating"
tasks sharing that single "thread of execution"?
> Of course, if we accept your definition whereby
> the two words mean exactly the same thing, then
> I am unable to name one. My answer presupposes
> that you pose a real question here.
QNX/Neutrino, IIRC, explicitly uses the term "thread".
[big snip]
> As I pointed out before, the term "task" has
> been used loosely. Perhaps not in your corner
> of the world, where a few vendors have settled
> on a consistent usage, but in the larger world.
> That fact alone is enough to motivate use of
> a word that more precisely conveys the concept
> of "thread of control". As I indicated before,
Yet, your use (above) of the term "thread" differs
substantially with mine. So, it's not a very "precise"
term, then, is it? :>
> "task" is a sloppy choice of words because it
> has ordinary meaning that too closely resembles
Agreed. The solution is to define your vocabulary in
any discussion in which the definitions affect the
clarity of the subject matter.
> the concepts involved when people use threads.
> (Commonly, they accomplish ongoing tasks.)
> >Windows insist on calling a task a thread. Unless and until someone
> >gives me some meaningful distinction between the two, I think it's
> >reasonable to ask why you insist on obfuscating the universe by
> >inventing new names for old things.
> If you truly believe that people who use the
> term "thread" do so intending to obfuscate,
> you are too far off the deep end to reason
I wouldn't go that far! :> MS has an annoying habit of
re-appropriating terms and defining them to suit it's
own marketing strategy. I can't wait to see how they
are going to redefine "real-time"! Probably something
along the lines of:
[When running on a Septium 1.35GHz processor with
a byte of memory for every soul on the planet,} achieves
"reasonably fast" performance [when compared to human *typing*
speeds] as a 4 function desk calculator...
Sounds about right when you see what they've done to the
terms "multitasking", "*real* multitasking", "VM", etc.
> with. I see the term in common use by many
> folks who are eminently reasonable and who
> obviously intend to communicate clearly.
> You may lament that the term has become
> popular, and rail upon its suspect origin,
> but those people, along with most others
> who use the term, will use it because they
> believe it conveys the meaning they intend.
[Soapbox is starting to creek threateningly... time for
me to step off... :>]
--don
Dom
"Jack W. Crenshaw" <jcr...@magicnet.net> wrote:
>Way back when Commodore was introducing the Amiga, some illiterate, but
>no doubt capable, software engineer labelled the OS kernel the "kernal."
>Manuals duly came out, describing the inner workings of the AmigaDos
>"kernal," and soon book stores were selling the equivalent of "AmigaDos
>Kernal for Dummies."
>
>When some of us who had read a dictionary pointed out the misspelling,
>people at Commodore put up a smoke screen of defense, arguing, amongst
>other things, that it was not a noun but a proper name. Others argued
>that it was an acceptable alternative spelling. AFAIK (again, feel free
>to correct me if you know more), Commodore never _DID_ admit it was just
>plain bad English. But that was what it was.
Spookeee... have you read today's Dilbert at www.unitedmedia.com?
LSPB
[snip]
|If anyone here can provide more info as to how a task got renamed a
|thread, or if there is some distinguishing difference between the two,
|I'm ready to be educate. Otherwise, I'm going to remain a reactionary
|old curmudgeon and use the original term.
I offer the following... lets consider this from a "point-of-view" approach.
In the following discussion, please consider this purely from an embedded
RTOS application standpoint.
From the point-of-view of the CPU, there is only a single thread and it
means something who's state is captured in the CPU hardware "register set."
From the point-of-view of the RTOS scheduler, there are different _types_ of
threads: interrupt-threads (both synchronous and asynchronous) and, yes,
task-threads. While the CPU has a point-of-view of a single thread, the
RTOS's point-of-view has multiple threads it "manages." We are further able
to differentiate threads and tasks from a standpoint of state data and
execution rules.
Execution rules: a interrupt-thread must run to completion. It must not
suspend. A task-thread can suspend and it also can "return." The return is
slightly tangential from this discussion, as it doesn't mean that the thread
continues (like a return from a sub-routine). Rather, the task-thread enters
a different state, which gets us to state data.
State data: Again, from the point-of-view of the RTOS scheduler, a
task-thread has the following states that do not make sense for an
interrupt-thread: executing; ready; suspended (further distinction is
sometimes added for conditional/unconditional); and finished (further
distinction is sometimes added for terminated/finished).
Now, can I simply take another step and say that a process is an instance of
an RTOS collection of task-threads and interrupt-threads (i.e. an RTOS
application)? And a "process-scheduler" preempts and slices up multiple,
concurrent RTOS applications? Now I'm out there, juggler exposed!
In another post on this same thread, I offer another answer from the
point-of-view of the RTOS user, or programmer. The user derives from what
the RTOS scheduler considers a task to be and extends it conceptually into
the application domain.
-Lance
Jack W. Crenshaw
>
> Jack W. Crenshaw wrote in message <366DBE...@magicnet.net>...
> >Larry Brasfield wrote:
> >>
> >> I believe that tasks are only coincidentally one-for-one
> >> with threads, and may not be in many systems. The
> >> words denote distinct concepts in my mind, especially
> >> during design.
> >
> >Name one.
>
> A "cooperatively multi-tasked" system has
> multiple tasks but need not have more than
> a single thread dedicated to its tasks.
Larry, forgive me for sounding skeptical, but as it stands the statement
is meaningless. Since you haven't defined either a task or a thread, I
have no way of knowing if it makes sense or not.
I guess my "name one" challenge was premature. Before we can discuss
the differences between threads and tasks, we must first define them.
What I'm looking for is definitions for the two that reveal something
they don't have in common. While we're at it, we'd better define
"process," since you use that term as well.
> >In your experience, does any RTOS vendor use the term "threads"?
>
> Not that I have seen. I am not prepared to say
> that RTOS vendors have the final word on usage.
Um ... come again? The people who build the systems can't define the
objects in them?
> >Now you've gone and introduced two _NEW_ term, "process," as well as
> >"process activation." Both terms come from the world of time-share
> >systems (e.g., Unix) and really have no place in a discussion of RTOS's.
>
> I do not view those worlds as being so disjoint. There
> is a continuum between them. I think you are mistaken
> if you believe that the concept denoted by "process"
> cannot be part of a realtime OS.
I never suggested that. However, since we still haven't agreed on the
definition of the term, "process," the question is moot.
> Given suitable latency
> guarantees, an OS that managed separate processes could
> still be wholly or partially an RTOS.
See above.
> My use of "process activation" is no more a new term
> here than "process" is. Your objection to new terms
> is getting a bit extreme, I think.
Sorry, I disagree. I see no reason to defend the invention of new terms
because folks are ignorant of the definitions of the old ones.
> >I'm pretty sure I gave the caveats, "as nearly as I've been able to
> >determine" and "AFAIK." Was there anything about these terms that you
> >failed to understand?
>
> No. I read them as statements of limited knowledge.
Do you have any reason to believe that I was mistaken?
> Let's see if I got your point. If Mr. Letwin
> invented the term "thread" himself, then you
> steadfastly refuse to consider whether it is
> a useful term or more useful than "task".
As you yourself point out, whether or not Gordon Letwin invented the
term "thread" is irrelevant. I'm perfectly prepared to accept the use
of the term "thread," as soon as someone explains to me how it differs
from what we embedded systems programmers have been calling a task,
since a time when you and Gordon were still shitting your diapers.
> I suggest, (and only suggest, because I see no
> point in persuasion), that the term "threads"
> has become popular for the same reasons that
> most terms do ...
And I'm suggesting that it's become popular only out of ignorance that
the object under discussion already _HAD_ a name.
> As I pointed out before, the term "task" has
> been used loosely.
Not by the people who have been using them all these years. It has a
very precise meaning. I'm suggesting that the term, "threads" arose
because the people who coined the term didn't know that meaning.
> That fact alone is enough to motivate use of
> a word that more precisely conveys the concept
> of "thread of control".
It conveys exactly nothing to me, so far. However, I'm certainly
willing to be educated. What, exactly, _DOES_ the term "thread of
control" mean?
> Inventing a word where none is already known
> needs no excuse.
On that we can agree. However, the word "task" (in the technical, not
the colloquial, sense) _IS_ already known, and has been for decades.
> There are excellent reasons
> for people to do that. The fact that another
> word from some isolated community ...
Isolated community? _ISOLATED_ _COMMUNITY_???? Only if you've never
dealt with a real-time system, or ever read a book about it.
> Your story is not analogous. Nobody would
> choose "kernal" over "kernel" because they
> thought it was clearer. People have adopted
> "thread" instead of "task" because the former
> term has not been muddied by indiscriminate
> use and is not likely to collide with other
> useful meaning in the same contexts.
Again, among people who use multitasking OS's, there has _NEVER_ been
any confusion as to what the term, "task," means. The fact that you
didn't know that its very precise, technical usage meant something quite
different from its usage in normal, everyday speech is immaterial.
Science is full of terms like energy, work, pressure, etc., whose
technical definitions, while extremely precise, mean something different
than their usage in colloquial speech. Would you re-invent those names,
as well?
Jack
Jack W. Crenshaw
Hadn't, until you pointed it out. But you're right: It _IS_ spooky!
Also very appropriate.
What's next? Threds?
Jack
Jack W. Crenshaw
>
> It seems to me that several people have mentioned that a task has a
> seperate static base and threads share them.
I don't know what this means. For a proper definition of a task, see
the Ada LRM.
> I also think that the terms fork and exec were used prior to UNIX. Perhaps
> on the PDP? I have worked on an OS where the original interrupt code was
> followed by a 'fork'.
Before Unix? I thought this was a Unix invention.
> There are several variations on my opening statement that can cloud the
> distinctions. The OS model will depend on resources and hardware that
> are available. Lets call them 'schedulable entities'. Whatever a task,
> thread, process, fork, etc are they can get executed seperately.
Ok, but if we're going to use the terms thread, process, task, _AND_
fork, we need some way to distinguish between them, agreed? Otherwise,
why not call them all a common name, say, "banana."
> Some OS's (or processors) only support absolute addressing. Some allow
> data relocation. Some processors have MMUs, some don't. Some OS's glob the
> entire static base together as a huge chunk of memory.
<snip for the sake of brevity>
I'm not sure what all of this has to do with the discussion. Unless, for
example, a task uses an MMU, and a thread does not, we still have no
basis for distinguishing them.
FWIW, I get the idea that many folks here feel that tasks cannot share
data. This is not so. Again, see the Ada LRM.
Jack
Jack W. Crenshaw
>
> Jack W. Crenshaw wrote in message <366DC0...@magicnet.net>...
>
> [snip] ...
>
> |People have been doing just fine, in the realtime world, with the term,
> task. I've asked
> |and asked folks to give me a real distinction between task and thread,
> |but so far, no one has.
>
> Ok, I see this has been posted to both comp.object and comp.realtime,
> therefore lets pull the two together.
Sorry about that. I didn't notice the cross-post until too late.
We use the following scheme in our
> OO-RTOS...
>
> The Thread is an enumerated set of sequential instructions presented to a
> CPU. A Thread means something to the RTOS scheduler. The Thread is presented
> to the RTOS scheduler as a frozen CPU state.
That is _PRECISELY_ the definition we've always ascribed to a task. The
task is the thing that gets switched when a context-switch occurs.
You bring up a good point, though. I do get the idea that the
introduction of the term, "thread" somehow coincided with the advent of
OO. Not too sure why; perhaps you can explain.
> Even in a "C", or service-based RTOS, the term Task represents the "more
> than the sum of the parts." The "more" includes data, collaboration (i.e.
> synchronization) and even other Thread interfaces into the Task. Further, a
> Task might include other RTOS widgets: Timers, Queues, Mutexes, ...
I disagree. The task is what the applications programmer writes. The
implementations of task communications are OS-dependent, and depend on
the way the OS is implemented.
<snip the C++ code>
> The above would not be classified as a "Process," nor can it be called a
> "Thread." Therefore, it must be called a "Task."
>
> Let the nitpicking begin!
> -Lance
Well, it is certainly apparent that what you call a task in your OS is
different that what we old-timers would call one. This issue is, is
this change of definitions justified?
Reminds me of when I first learned to write Fortran programs. We had to
write them on coding forms for a keypunch operator to punch, so
characters had to be completely unambiguous. To distinguish between an
"oh" and a "zero," we were taught to put a slash through the "oh." To
be doubly safe, many of us also put an underline under a "zero."
All of this worked very nicely, until the advent of minicomputers with
CRT terminals like the ADM-3. Imagine our horror to discover that the
character generators slashed the zero, not the "oh." Suddenly, we all
had to change.
We managed it; didn't have much choice, since the character generators
were hardware. However, there was a considerable overlap time there
where confusion reigned supreme. I see no reason to go through such
chaos again, without a very good reason.
Jack
Jack W. Crenshaw
>
> First use I remember was in "Communicating Sequential Processes" by
> C.A.R. Hoare back in the 70's. He spoke about using multiple
> "threads of control".
I have the book. I'll check.
Jack
Richard Pennington
>
> Well, it is certainly apparent that what you call a task in your OS is
> different that what we old-timers would call one. This issue is, is
> this change of definitions justified?
Probably not.
>
> Reminds me of when I first learned to write Fortran programs. We had to
> write them on coding forms for a keypunch operator to punch, so
> characters had to be completely unambiguous. To distinguish between an
> "oh" and a "zero," we were taught to put a slash through the "oh." To
> be doubly safe, many of us also put an underline under a "zero."
Was that for an O26 or an O29 keypunch? It's been a long time.
>
> All of this worked very nicely, until the advent of minicomputers with
> CRT terminals like the ADM-3. Imagine our horror to discover that the
> character generators slashed the zero, not the "oh." Suddenly, we all
> had to change.
I wish I still had my adm3. I have a vt220 though. Shows control
characters and everything.
>
> We managed it; didn't have much choice, since the character generators
> were hardware. However, there was a considerable overlap time there
> where confusion reigned supreme. I see no reason to go through such
> chaos again, without a very good reason.
>
> Jack
I call "tasks" threads in my CREX executive. Primarily because the
context is:
offset 0 ; thread table entry
cx_next ds.w 1 ; next running, locked,
waiting
cx_address ds.w 1 ; event address
cx_stack ds.w 1 ; start of stack
cx_context ds.w 1 ; thread context
(current sp)
cx_status ds.b 1 ; thread status
cx_priority ds.b 1 ; thread priority
cx_sizeof_thread equ * ; size of thread entry
My thinking was that a task (really a process in "newspeak") had
more in it.
Although in the olden days my thing could be called a task.
Are you the same "Jack Crenshaw" that I remember from the early days?
If so, I'll promptly change my terminoligy from "thread" to "task" in
deference to a man that taught me much.
Otherwise, "thread" is much more trendy. :)
-Rich
--
Richard Pennington Introl Corporation, Milwaukee, WI USA
Email: ri...@introl.com Phone: +1 414-273-6100 Fax: +1 414-273-6106
US and Canada: 1 800-327-7171
Cross development tools for the 68HC05, 68HC08, 6809, 68HC11, 68HC12,
68HC16,
and 68XXX: http://www.introl.com ftp://ftp.introl.com
Gerhard Menzl
> For the record, I flat-out refuse to accept the term "thread," which
> seems to be indistinguishable from a task, in discussions of real-time
> systems. There may be some prior use of the term I'm not aware of, but
> as nearly as I've been able to determine, the term, "threads," was
> introduced by J. Gordon Letwin in his original version of OS/2, which
> was about as far removed from a real-time system as it's possible to
> get. Also AFAIK, JGL never wrote a real-time system in his _LIFE_, so
> I'm not prepared to let him rename the term, "task," for me.
>
> If anyone here can provide more info as to how a task got renamed a
> thread, or if there is some distinguishing difference between the two,
> I'm ready to be educate. Otherwise, I'm going to remain a reactionary
> old curmudgeon and use the original term.
While I understand your frustration about the constant terminology shift, I think
this is a phenomenon in this fledgling engineering discipline we have no choice
but to cope with. I am confronted with three operating systems in my daily work,
and each of them has a different notion for what is essentially the same concept:
Windows NT calls it a thread, in VxWorks, it's a task, and OSE (which is an RTOS,
mind you!) has processes. The latter two don't have an equivalent for what is a
process in Windows NT, unlike Unix, which distinguishes between processes and
lightweight processes. Just for the sake of confusion, Microsoft added fibres to
their Win32 API. Now let's not get into semaphores and mutexes. Client/server,
anyone?
If you want to stay abreast in the field, you have to be flexible with respect to
terminology, I think, just as you have to be prepared for overlapping and even
conflicting meanings of similar terms in different natural languages. Which does
not mean that one has to accept every sloppy use of a well-defined term, of
course. But the notion of a thread has become too widespread to fight it.
Gerhard Menzl
Simon Wright
> You're further confusing the issue here. Semantically, these are
> still different "threads"/"tasks". You analogy is akin to
> implementing a package like pthreads and *multiplexing* those
> threads onto some *other* number of kernel threads in the
> implementation (as if that won't confuse things more! :>)
I /think/ that Solaris does this -- beats me
--
Simon Wright (G-net) +842-1778
GEC-Marconi RDS Ltd (voice) +44(0)1705-701778
Command & Information Systems Division (fax) +44(0)1705-701800
Don Yuniskis
> In article <74m3tf$9nh$1...@remarQ.com> Don Yuniskis <d...@cutout.gci-net.com> writes:
> > You're further confusing the issue here. Semantically, these are
> > still different "threads"/"tasks". You analogy is akin to
> > implementing a package like pthreads and *multiplexing* those
> > threads onto some *other* number of kernel threads in the
> > implementation (as if that won't confuse things more! :>)
> I /think/ that Solaris does this -- beats me
Quite possible -- when you layer a package on top of an existing
kernel implementation. Rather than force a one-to-one
correspondence between "your" threads and the kernel's,
you can have your package maintain some of this detail
and create a set of "virtual threads" that *your* package
multiplexes onto the kernel's. In the degenerate case,
perhaps just a single kernel thread which is used to "run"
each of N discrete "your" threads, etc.
If you thought tracking terms like thread, task, process, etc.
was a pain, imagine when you have these concepts applying
(possibly with different semantics!) at two (or more!?)
different layers in an implementation. Argh!
"Thread? What *kind* of thread?? Which scheduler
handles it -- the in-kernel or in-process scheduler?..."
--don
Foundation for Obfuscating Old Technology (F.O.O.T.)
Emil P. Rojas
Isn't this thread, ur ... discussion , a little silly.
When folks use new words to try and refine an idea it
can never satisfy everyone that has a history with
the idea.
It works for me, even though I scratched my head the
first time I heard it.
The word "threads" was introduced first into process
oriented OSs. The first reference I remember was with
regards to the Mach OS.
The word was intended to be discriptive of a time
view of tasks carried out within a single process.
A thread was light weight compared to a process,
so the term captured for the creator this ligher
notion.
At the time "threads" was introduced "tasks" were king
in the micro based RTOS world. The first 32-bit
micros with MMU where just being introduced. Few
embedded systems had aspirations beyond 16-bit micro
with 265K of RAM and 256K of ROM.
The world of real-time has grown up, it needs both
the concept of processes and threads every bit
as much as Unix or NT workstations do. This does
not mean that the term "tasks" should be banished,
or that it is not useful. It is just that
it does not distinguish between the protected address
space notions and the shared address space notion and
therefore is not robust enough to discribe what is going
on in many modern RTOSs.
emil
Mati Sauks
here is earliest reference to "threads" that I found on CMU MACH web
site..
Eric C. Cooper and Richard P. Draves. C Threads. [abstract] [postscript]
[doc] Technical Report CMU- CS-88-154, School of Computer
Science, Carnegie Mellon University, February 1988.
"abstract:
The C Threads package allows parallel programming in C under the Mach
operating system. The package provides multiple threads of control
within a single shared address space, mutual exclusion locks for
protection of critical regions, and condition variables for thread
synchronization.
"
I think this concept was extended into SVR4, which then ended up in
Solaris 2.00 as solaris threads. Posix then standardized it as
Pthreads.
"Emil P. Rojas" wrote:
--
===========================================================
"The RTOS Solution Company"
Mati Sauks Precise Software Technologies Inc.
Tel: 613-596-2251 x223 Suite 308, 301 Moodie Dr.
Fax: 613-596-6713 Nepean, ON Canada, K2H 9C4
Email: ma...@psti.com URL: www.psti.com
Ziv Caspi
> Now you've gone and introduced two _NEW_ term, "process," as well as
> "process activation." Both terms come from the world of time-share
> systems (e.g., Unix) and really have no place in a discussion of RTOS's.
I don't follow your argument. If people here started talking about "jobs"
would you object? (RMX, I seem to recall, has these.)
[...]
> Personally, I don't care _HOW_ many of you folks who grew up with
> Windows insist on calling a task a thread.
This has nothing to do with Windows. The names used by Win32/NT
*probably* came (like everything else in Win32/NT ;-) from VMS.
Remember - Windows 3.x actually used the term task (and actually
claimed it was a cooperative multi-tasking system).
> Unless and until someone
> gives me some meaningful distinction between the two, I think it's
> reasonable to ask why you insist on obfuscating the universe by
> inventing new names for old things.
I can only answer for myself: because I think "thread" is a much
better description than "task". (There's that quote about "consistency"
and "hobgolins of the mind", but fool is not a term I'd use for you.)
--------------------------------
Ziv Caspi
zi...@netvision.net.il
Jack W. Crenshaw
>
> This has nothing to do with Windows. The names used by Win32/NT
> *probably* came (like everything else in Win32/NT ;-) from VMS.
> Remember - Windows 3.x actually used the term task (and actually
> claimed it was a cooperative multi-tasking system).
Please repeat after me:
o VMS is not a real-time system
o Unix is not a real-time system
o Multics is not a real-time system
o Windows NT is not a real-time system
o Windows 95 is not a real-time system
o Windows 98 is not a real-time system
o Windows 3.1 is not a real-time system
o Solaris is not a real-time system
...
I guess you get the picture.
Jack
Jack W. Crenshaw
>
> Was that for an O26 or an O29 keypunch? It's been a long time.
Doesn't matter. Company "guidelines" were the same for both.
> I call "tasks" threads in my CREX executive. Primarily because the
> context is:
>
> offset 0 ; thread table entry
> cx_next ds.w 1 ; next running, locked,
> waiting
> cx_address ds.w 1 ; event address
> cx_stack ds.w 1 ; start of stack
> cx_context ds.w 1 ; thread context
> (current sp)
> cx_status ds.b 1 ; thread status
> cx_priority ds.b 1 ; thread priority
> cx_sizeof_thread equ * ; size of thread entry
>
> My thinking was that a task (really a process in "newspeak") had
> more in it.
Nope. What you describe is exactly what I would expect in a real-time
task. A process _WOULD_ have more in it.
> Are you the same "Jack Crenshaw" that I remember from the early days?
I dunno, but could be. Where do you remember me from?
> If so, I'll promptly change my terminoligy from "thread" to "task" in
> deference to a man that taught me much.
Wow! Thanks.
Jack
Jack W. Crenshaw
>
> unlike Unix, which distinguishes between processes and
> lightweight processes.
Gack!
> Just for the sake of confusion, Microsoft added fibres to
> their Win32 API.
<Sticking finger down throat!>
Jack
Jack W. Crenshaw
>
> The world of real-time has grown up, it needs both
> the concept of processes and threads every bit
> as much as Unix or NT workstations do. This does
> not mean that the term "tasks" should be banished,
> or that it is not useful.
I want to make it clear that I am not against progress. If the terms
"process" and "task" and "thread" and <ugh> "fiber" (what's next, DNA?)
really _CONTRIBUTE_ something, and really are different things, then I'm
all for using the terms needed to distinguish them. I'm still waiting
for someone to explain to me the difference between what we old-timers
have always called tasks, and from what these young whippersnappers call
threads. So far, I haven't found one. I say again, coining a new name
simply because one was ignorant that the old name existed, doesn't cut
it.
> It is just that
> it does not distinguish between the protected address
> space notions and the shared address space notion and
> therefore is not robust enough to discribe what is going
> on in many modern RTOSs.
By "it," do you mean the term, "task"? If so, you're mistaken.
Protected addresses and shared memory have been part of "modern" RTOS's
since the 1970's.
Jack
Foobar T. Clown
>
> This has nothing to do with Windows. The names used by Win32/NT
> *probably* came (like everything else in Win32/NT ;-) from VMS.
Not everything. Windoze NT ripped off a lot of it's ideas from
Carnegie-Mellon University's operating system, Mach.
The whole hairy Component Object Model (a.k.a., COM, a.k.a., ActiveX)
appears to have some roots in Mach's IPC mechanism, and the COM
Interface Description Language (IDL) strongly resembles the language,
Matchmaker, that was used by Mach.
Loadable Kernel Servers and sub-systems (e.g., NT's POSIX subsystem and
Win32 subsystem) were a design goal of Mach from the beginning. Mach
never developed them to the same extent as in Windows NT, but it did
reach the point where most of its Unix-like features were encapsulated
in an optional "BSD subsystem" that ran at a less privileged level than
the kernel.
All of the process and thread calls, and all of the VirtualXxxxxx()
calls also resemble Mach services, especially in the way that a
"process" is an object that owns a virtual address space, and a "thread"
is an object, bound to a process, that owns a context and is managed by
the scheduler.
Oh, and one more thing; two or three years before Windoze NT was
released, Rick Rashid, the principle architect of Mach, was hired away
from C-MU by Microsoft to be head of a new, major product devlopment
effort which he was not allowed to talk about at the time.
Michael Lyle
>
> > I also think that the terms fork and exec were used prior to UNIX. Perhaps
> > on the PDP? I have worked on an OS where the original interrupt code was
> > followed by a 'fork'.
>
> Before Unix? I thought this was a Unix invention.
>
Nah, the first time I heard of fork was in the context of a fork-join pair.
I went looking for the machine, and couldn't figure out which one it was:
maybe a KDF-9 or a Bull Gamma-60?. One of those late 50's early 60's
machines. Long before the concept of a process was introduced.
IBM used the exec call to overlay at least as early as OS-MFT on 360's. ~1965.
The original definition of a process I saw was "a program in execution": a
program, memory context, register context, and an instruction pointer. The
reason "process" was chosen as a name was that "task" and "job" had
specific different meanings for IBM, Burroughs, Univac, SDS, and others.
So, to differentiate, "process" was picked.
The fledgling Computer Science community picked up on that usage, and it
stuck. Along comes the idea of "multi-programming", and "process" gets the
extra baggage of a protected address space (what IBM represented with a
partition, and Burroughs represented as a stack.)
So what about something that acts like a process in every way but shares
address space (both I/O and memory) with other somethings: IBM calls it a
"task", and Burroughs wrestles with "cactus stacks", since they already
picked stacks to implement "processes". Of course they didn't call them
processes, they called them something else that escapes me at the moment.
(See Organick's book on the B6700 for a discussion of cactus stacks.)
The academic community needs a new term, and picks "thread". But wait,
that won't do for the operating system point of view, so the academics pick
"lightweight process", and the result is Sun's Solaris. Solaris has
threads for the program, lightweight processes for the OS, and processes
for partitions.
What next? Maybe we'll need something to cover "applets", "objects", and
"servlets". Who knows? I see from the Galaxy discussion over in comp.arch
that we need some term for the cluster-like partition of a multiprocessor.
The upshot of this is that the old terms usually give way to the new terms,
not because the new terms are better, but because the new terms are less
ambiguous in the academic community. They don't carry the old baggage. I
don't like it either, because I am old baggage myself, but I am very used
to multiple terms in English for the same concept.
--
Michael
Michael Lyle (ml...@wco.com)
david thompson
10 Dec 1998 03:35:45 GMT in <366F68...@magicnet.net>
"Jack W. Crenshaw" <jcr...@magicnet.net> responded:
> Bill Pringlemeir wrote: ...
> > I also think that the terms fork and exec were used prior to UNIX. Perhaps
> > on the PDP? I have worked on an OS where the original interrupt code was
> > followed by a 'fork'.
>
> Before Unix? I thought this was a Unix invention.
>
I recall "fork" and "join" being used in the early 70s,
at least academically (Hoare?), for starting and ending
concurrent execution contexts, usually (perhaps pedagogically)
within the same code and data space but sometimes otherwise.
The concept of "replace current executing program with a
new one" was certainly present in other systems e.g. Dartmouth
BASIC "CHAIN" although not AFAIK under the name "exec".
I believe the Unix invention (in this area) was to observe
that two primitives in the OS:
- fork: create new process with cloned data, cloned code
or shared if readonly, and shared fileopens;
- exec: start running new code with (re)initialized data
in existing process with (usually) existing fileopens;
are sufficient as they can be combined by the application
(or library) to provide the much more common (and obvious):
- spawn: create a new process running new code with initialized
data (and perhaps specified fileopens);
but can also used in other ways e.g. "sh" sequencing and
control constructs, login handler, transparently multipass
compilers, etc.
Thu, 10 Dec 1998 00:20:41 -0600 in <366F6839...@introl.com>
Richard Pennington <ri...@introl.com> responded:
> Jack W. Crenshaw wrote: ...
> > Reminds me of when I first learned to write Fortran programs. We had to
> > write them on coding forms for a keypunch operator to punch, so
> > characters had to be completely unambiguous. To distinguish between an
> > "oh" and a "zero," we were taught to put a slash through the "oh." To
> > be doubly safe, many of us also put an underline under a "zero."
>
> Was that for an O26 or an O29 keypunch? It's been a long time.
>
> > All of this worked very nicely, until the advent of minicomputers with
> > CRT terminals like the ADM-3. Imagine our horror to discover that the
> > character generators slashed the zero, not the "oh." Suddenly, we all
> > had to change.
>
> I wish I still had my adm3. I have a vt220 though. Shows control
> characters and everything.
>
The irony here is delicious -- the IBM keypunch models were numeric
zero-two-six and -nine, not (as often mis-said) "oh". Seriously,
the Teletype 33, and I believe also 35, had zero slashed and
cap-oh empty. Then-new video terminals were mostly intended to
replace Teletypes and so probably chose to follow that "standard".
(They certainly mostly used ASCII rather than Hollerith/EBCDIC!)
IIRC early 3270s, which IBM presumably expected to mostly replace
card/print RJE stations, had cap-oh empty and a center dot in
zero. I can't remember now what IBM considered official printer
glyphs, though with customizable chains on the 1403 I think a shop
could get pretty much anything they wanted.
I just missed the ADM-3, but the -3A was the Volkswagen of VDTs:
cheap, looks silly, runs great. DEC (RIP) >=VT100 also excellent.
- David.Thompson at but not for Trintech.com
dls2
>Emil P. Rojas wrote:
>>
>> The world of real-time has grown up, it needs both
>> the concept of processes and threads every bit
>> as much as Unix or NT workstations do. This does
>> not mean that the term "tasks" should be banished,
>> or that it is not useful.
A process is not a thread, and not a task.
A thread is not a process, and not a task.
A task is not a thread, and not a process.
Each term is unique, yet can be used more or less
interchangably, because there is not much need to
distinguish between the three terms. People who
distinguish between terms are capable of inferring
when a term should be otherwise. People who do
not distinguish between terms do not care to infer
the differences, because to them, either the
meaning is clear, or `they just don't give a damn.'
A process is...all steps to completion of a task.
A thread is...a step to completion of a task.
Threads, sometimes fibers, may be woven.
The act of weaving is akin to programming
in the skill required, which is why it serves
the purpose of being a common comparison.
A thread is a step, and a step may be many
instructions chained together. Consideration
depends upon the granularity of analysis.
A task is...something to be accomplished.
Rhetorically, what are the differences between calls,
functions, and procedures?
A call exists as either a function or a procedure, and
invokes a routine, a.k.a. sub-program.
Functions and procedures are more or less the same,
in that they both invoke a routine. The difference
between the two is that a function returns values,
whereas a procedure does not return values.
Same difference(s); see?
I am flexible in the use of terms; both in allowing
others to use terms incorrectly, and using terms
incorrectly, myself. Language is a means to an
end. Remember the parable of Babel, please.
>I want to make it clear that I am not against progress. If the terms
>"process" and "task" and "thread" and <ugh> "fiber" (what's next, DNA?)
>really _CONTRIBUTE_ something, and really are different things, then I'm
>all for using the terms needed to distinguish them. I'm still waiting
>for someone to explain to me the difference between what we old-timers
>have always called tasks, and from what these young whippersnappers call
>threads. So far, I haven't found one. I say again, coining a new name
>simply because one was ignorant that the old name existed, doesn't cut
>it.
Actually, it does. To justify your position that coining a new name simply
because one was ignorant that the old name existed requires justifying
the existance of the entire English language as apart from other languages.
I merely have to cite one word, from a more ancient language, which
English does not use, to put your argument in doubt.
Unfortunately, I don't remember any. ;)
>> It is just that
>> it does not distinguish between the protected address
>> space notions and the shared address space notion and
>> therefore is not robust enough to discribe what is going
>> on in many modern RTOSs.
>
>By "it," do you mean the term, "task"? If so, you're mistaken.
>Protected addresses and shared memory have been part of "modern" RTOS's
>since the 1970's.
>
>Jack
There are many languages and means of expression to describe,
and possibly implement, a concept. Why limit yourself to just one?
Processes and threads describe tasks as much as tasks describe
processes and threads. Protected addresses and shared memory
can exist, and be described, without any notion of processes,
threads, or tasks.
Derrick Shearer
dl...@Lehigh.EDU
Pat Rogers
<snip>
>Ada is sharing data true, however the sharing is synchronized.
Other
>methods of sharing task data include mutex, semaphores, message
queues,
>etc found in POSIX and other operating systems. The methods are a
function
>of an operating system. Since Ada defines scheduling in the
language
>semantics, it is very clear what a task is. For assembler, 'C',
C++,
>Pascal, lisp, etc this is not part of the language definition.
(perhaps
>Forth is the same as Ada?)
Well, it is synchronized if you want things to work right, but it is
your responsibility to provide the synchronization if you use shared
data. If you use the other mechanisms, the synchronization comes
along by definition.
Ada programs can use all the above mechanisms, by the way. For
example, there is (and has been for quite some time) a binding to
POSIX.
>I believe the original question related to OS's and the meaning of
task and
>thread. This is what I was trying to answer. Ada is inflexible in
the
>way that tasks can relate. Closely coupled tasks may not need the
same
>context changes as completely unrelated tasks. Access rights also
incurs
>context switch overhead. This may not be neccessary or needed for
closely
>coupled tasks. However, it may be desireable for security and
safety reasons
>to restrict access to some other tasks.
Defining the term "task" in the language provides a number of
benefits, but it doesn't define the relationship between a task and
an OS-schedulable-entity. In the old days, for example, all the
tasks in a program were often mapped into one Un*x process, and sure
enough, when one task made a blocking (eg I/O) call, the entire
process blocked and the other tasks didn't continue. (Strangely,
some thought this to be a failing of the language.) Other
implementations mapped indivudual tasks to processes -- the Sequent
Balance series did this, with the result that Ada tasks got mapped
to distinct processors, so they ran in parallel. Nowadays modern
OS's tend to map the Ada tasks to the things that the OS can
schedule independently. (I'm thinking of SGI and Irix, for
instance.) The point is that the language defines the semantics of
task interactions, providing a strong measure of OS-independence,
but the standard doesn't say how an underlying OS (if there is one)
manages them, other than:
RM 9.0(11):
"Concurrent task execution may be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can
determine that the required semantic effects can be achieved when
parts of the execution of a given task are performed by different
physical processors acting in parallel, it may choose to perform
them in this way."
Which means one can map an entire task to some schedulable entity,
or individual statements within a task can be executed in parallel
(e.g. a loop).
---
Pat Rogers Training & Development in:
http://www.classwide.com Deadline Schedulability Analysis
pro...@acm.org Software Fault Tolerance
(281)648-3165 Real-Time/OO Languages
Don Yuniskis
> > Ziv Caspi wrote:
> >
> > This has nothing to do with Windows. The names used by Win32/NT
> > *probably* came (like everything else in Win32/NT ;-) from VMS.
> Not everything. Windoze NT ripped off a lot of it's ideas from
> Carnegie-Mellon University's operating system, Mach.
Why should that be surprising? Rick Rashid (Mach's "father")
went to work for MS after Mach.
> The whole hairy Component Object Model (a.k.a., COM, a.k.a., ActiveX)
> appears to have some roots in Mach's IPC mechanism, and the COM
> Interface Description Language (IDL) strongly resembles the language,
> Matchmaker, that was used by Mach.
> Loadable Kernel Servers and sub-systems (e.g., NT's POSIX subsystem and
> Win32 subsystem) were a design goal of Mach from the beginning. Mach
> never developed them to the same extent as in Windows NT, but it did
> reach the point where most of its Unix-like features were encapsulated
> in an optional "BSD subsystem" that ran at a less privileged level than
> the kernel.
Mach doesn't need "Loadable Kernel Servers" because the entire premise was
to move the servers out to user-land. As such, all you need to do
to "load" a server is just start it as a regular user process,
let *it* register itself with the name server, and then have it wait
for requests on it's public port(s).
The BSD "single server" (bsdss) was a monolithic UN*X "emulator"
that ran in userland. Likewise with Mach-US and Mach-UX (though
they were migrated towards a multi-server approach). The goal of
Mach (and RT-Mach, TMach, etc.) was that *everything* should run
outside the (microkernel) -- hence the basis of the entire
(MK) architecture.
> All of the process and thread calls, and all of the VirtualXxxxxx()
> calls also resemble Mach services, especially in the way that a
> "process" is an object that owns a virtual address space, and a "thread"
> is an object, bound to a process, that owns a context and is managed by
> the scheduler.
> Oh, and one more thing; two or three years before Windoze NT was
> released, Rick Rashid, the principle architect of Mach, was hired away
> from C-MU by Microsoft to be head of a new, major product devlopment
> effort which he was not allowed to talk about at the time.
Mach's big problems are associated with the "not cheap"
cost of crossing all those protection domains. Since a server
runs in user land, every access to it requires a "hit" into
and out of that domain. I.e. IPC isn't cheap. Add support for things
like external Memory Managers and a good portion of the system
can be spent hopping back and forth across those domain boundaries.
And, ongoing support for Mach is nonexistent. Even the RT-Mach
crowd seems to basically just be a bunch of students effectively
*employed* by a few key sponsors. (sigh) A good idea that fizzled...
IIRC, Chorus used a good bit of the Mach concepts. As did NeXT's
OS (?).
--don
Steven Perryman
Reading the postings, it is easy to see how confusion arises by different
prog langs and OSs giving differing definitions of process/task/thread.
The definitions I try to use are the ones I first saw used by the ANSA
platform (a distributed systems infrastructure) .
Their definitions (roughly, cos I don't have the source doc(s) to hand) were :
A thread is a unit of work/activity, executing in a system.
A task is an entity that provides the environment/resources that allows threads
to be able to operate.
So examples of a task by this definition could include Unix processes, the Ada
'task' type etc.
Regards,
Steven Perryman
ste...@nortel.co.uk
Erik Funkenbusch
news:36707A...@magicnet.net...
>I want to make it clear that I am not against progress. If the terms
>"process" and "task" and "thread" and <ugh> "fiber" (what's next, DNA?)
>really _CONTRIBUTE_ something, and really are different things, then I'm
>all for using the terms needed to distinguish them. I'm still waiting
>for someone to explain to me the difference between what we old-timers
>have always called tasks, and from what these young whippersnappers call
>threads. So far, I haven't found one. I say again, coining a new name
>simply because one was ignorant that the old name existed, doesn't cut
>it.
The reason that terms evolve is because technology evolves. It seems to me
that when term "task" was coined it was used in conjunction with
environments like CICS and similar environments which differentiated between
the time slice in a partitioned environment (as used in multi-programming
environments) and a given task to be executed within that environment.
As OS's evolved and became "multi-tasking" as opposed to "multi-programming"
the term task was re-used to refer to individual tasks in the system. It's
likely that the term task was not unique enough and didn't distinguish
between different kinds of execution primitives.
In those days, multi-programming systems (such as most IBM mainframes) had
the basic execution unit as the program. Thus, being able to run multiple
programs was multi-programming. In a Multi-tasking OS, the basic unit of
execution was the task. A task could be a program, but it didn't have to
be. It could be a subprogram within a program. More specifically,
multi-tasking meant that the executive didn't have to keep track of things
on a per-program basis. It kept track of them on a per-task basis. A
common theme in those days were people saying something like "I refuse to
accept the term task when it really means program" Refusing to accept a new
term quite often means refusing to accept that technology has changed.
If you look at a modern OS such as today's Unix or NT you'll find many
different kinds of execution primitives. A Task in today's OS's would seem
to be generic, and apply to any execution primitive. While threads,
processes, and fiber's have specific meaning and specific characteristics.
These terms are simply specializations of the term task.
In unix, a process is the basic unit of execution, with threads available as
more specific units. Processes can exist without threads.
In NT A process in an environment without any kind of execution of it's own.
A process must contain at least one thread, which is the primary thread. A
Fiber is a controlled unit of execution. Fibers are not scheduled by the
scheduler, they are scheduled by a the controlling thread.
To confuse matters more. The AmigaOS (1985) only had threads, it didn't
have processes since it used a single VM approach. Different threads could
interoperate with each other without any distiction of who owned what.
Terminology doesn't stay static because the technology upon which the
terminology was coined doesn't stay static. Unix Processes, threads and
fibers are all tasks, but they all have very specific meaning and
characteristics in today's OS's that didn't exist when the term Task was
coined.
Emil P. Rojas
Don Yuniskis wrote:
>
>
> Mach doesn't need "Loadable Kernel Servers" because the entire premise was
> to move the servers out to user-land. As such, all you need to do
> to "load" a server is just start it as a regular user process,
> let *it* register itself with the name server, and then have it wait
> for requests on it's public port(s).
To investigate these ideas further look into the "exokernel."
[snip]
>
> Mach's big problems are associated with the "not cheap"
> cost of crossing all those protection domains. Since a server
> runs in user land, every access to it requires a "hit" into
> and out of that domain. I.e. IPC isn't cheap. Add support for things
> like external Memory Managers and a good portion of the system
> can be spent hopping back and forth across those domain boundaries.
Much work has been done since the time of Mach that shows that
this cost can be made very small. The system and author names
elude me at the moment, but some of the groups are CMU, Wash. U.,
Stanford, and some European (German?) group. Also, I'm sure the
folks at QNX would claim the cost can be very reasonable.
>
> And, ongoing support for Mach is nonexistent. Even the RT-Mach
> crowd seems to basically just be a bunch of students effectively
> *employed* by a few key sponsors. (sigh) A good idea that fizzled...
>
> IIRC, Chorus used a good bit of the Mach concepts. As did NeXT's
> OS (?).
NeXT == Mach
p.s.
I apologize for making refernces without providing details, but it would
take more time than I have this morning.
Don Yuniskis
> Don Yuniskis wrote:
> >
> > Mach doesn't need "Loadable Kernel Servers" because the entire premise was
> > to move the servers out to user-land. As such, all you need to do
> > to "load" a server is just start it as a regular user process,
> > let *it* register itself with the name server, and then have it wait
> > for requests on it's public port(s).
> To investigate these ideas further look into the "exokernel."
I think the exokernel (MIT?) tries to even further reduce the
framework that it supplies to "tasks"/servers/etc.
> > Mach's big problems are associated with the "not cheap"
> > cost of crossing all those protection domains. Since a server
> > runs in user land, every access to it requires a "hit" into
> > and out of that domain. I.e. IPC isn't cheap. Add support for things
> > like external Memory Managers and a good portion of the system
> > can be spent hopping back and forth across those domain boundaries.
> Much work has been done since the time of Mach that shows that
> this cost can be made very small. The system and author names
> elude me at the moment, but some of the groups are CMU, Wash. U.,
> Stanford, and some European (German?) group. Also, I'm sure the
> folks at QNX would claim the cost can be very reasonable.
QNX's approach to a "microkernel" is considerably different
than Mach's :-/ At the very least, QNX doesn't treat "ports"
as "protected entities". This in itself adds more complexity
(spell that "t-i-m-e") to IPC. (FWIW, I think the concept
of protected ports is one of the most delightful features of Mach!
What good is "protected address spaces" if "anybody" can send
messages to any port, etc.??)
You are omitting Utah's "FlexMach" from your list.
> > And, ongoing support for Mach is nonexistent. Even the RT-Mach
> > crowd seems to basically just be a bunch of students effectively
> > *employed* by a few key sponsors. (sigh) A good idea that fizzled...
> >
> > IIRC, Chorus used a good bit of the Mach concepts. As did NeXT's
> > OS (?).
> NeXT == Mach
IIRC, NeXT was based on an older Mach version (2.5?). This was
contemporary with the bsdss package. I.e. I assume NeXT's OS
*isn't* a "multi-server"?
I think one of DEC's products was also Mach derived (?)
> p.s.
> I apologize for making refernces without providing details, but it would
> take more time than I have this morning.
Heh heh heh... you and the *rest* of us! :>
--don
Emil P. Rojas
"Jack W. Crenshaw" wrote:
>
> Emil P. Rojas wrote:
> >
> > The world of real-time has grown up, it needs both
> > the concept of processes and threads every bit
> > as much as Unix or NT workstations do. This does
> > not mean that the term "tasks" should be banished,
> > or that it is not useful.
>
> I want to make it clear that I am not against progress. If the terms
> "process" and "task" and "thread" and <ugh> "fiber" (what's next, DNA?)
> really _CONTRIBUTE_ something, and really are different things, then I'm
> all for using the terms needed to distinguish them. I'm still waiting
> for someone to explain to me the difference between what we old-timers
> have always called tasks, and from what these young whippersnappers call
> threads. So far, I haven't found one. I say again, coining a new name
> simply because one was ignorant that the old name existed, doesn't cut
> it.
>
> > It is just that
> > it does not distinguish between the protected address
> > space notions and the shared address space notion and
> > therefore is not robust enough to discribe what is going
> > on in many modern RTOSs.
>
> By "it," do you mean the term, "task"? If so, you're mistaken.
> Protected addresses and shared memory have been part of "modern" RTOS's
> since the 1970's.
>
> Jack
Well, from my prespective the discussion has grown old.
I think many arguemnts have been made that should convince one
that the trem "threads" is a resonable term in the context
that they were introduced. That is, that threads were introduced
in the context of "heavy weight" process oriented systems, and
that the "light weight" nature of local context switches needed
a new name to identifying its distinguishing characteristics. To those
of us used to working on unprotected systems these ideas seem
rather obvious. I would not be surprised if the idea for threads
came from working on an embedded system. Furthermore, the power of this
"new" idea in the shared-computer environment changed the
way applications are written those platforms, and subsequently on
all platforms. Then this new term found its way into
the RTOS world. Why? To facitate communication.
emil
Tom Maier
>At the time "threads" was introduced "tasks" were king
>in the micro based RTOS world. The first 32-bit
>micros with MMU where just being introduced. Few
>embedded systems had aspirations beyond 16-bit micro
>with 265K of RAM and 256K of ROM.
Yes.
I think this clash of terminolgy comes from two separate
camps of computer programmers who have collided; the
small scale embedded rtos people and the large, multiuser,
mainframe system programmers.
In the early days a multitasking kernal
was a simple switcher used on, perhaps, an embedded
8080 that was controlling an industrial process. These
task switchers became more sophisticated over time
and developed their own terminolgy (and concentrated
on slightly different goals).
Programmers on the larger systems using mainframes
came up with their own terminolgy for similar
concepts (like threads). Now that powerful hardware
is readiliy available more of these grandiose os's
are being embedded (like NT) and the vocabulary
is running head-first into that of the old embedded
control world. It's pretty common to see full-blown
file-based os systems running the automation that
used to be done with small, tight, kernals on
more limited hardware (just as you mention).
So embedded programmers need to learn more
desktop/mainframe type os terminology. It's going
to spread and take over in the long run.
And that my opinion on how this mess came about...
Tom
Foobar T. Clown
>
> IIRC, NeXT was based on an older Mach version (2.5?). This was
> contemporary with the bsdss package. I.e. I assume NeXT's OS
> *isn't* a "multi-server"?
Correct. The version of Mach that NeXT computer grabbed was just a copy
of BSD Unix with Mach system calls hacked into it. Mach didn't get
really interesting until Mach 3 -- the first version where they took the
Unix system calls out, and moved all of the Unix-like services into a
user-level process.
May your life be interesting.
-- Ancient, anonymous curse
Don Yuniskis
> Don Yuniskis wrote:
> >
> > IIRC, NeXT was based on an older Mach version (2.5?). This was
> > contemporary with the bsdss package. I.e. I assume NeXT's OS
> > *isn't* a "multi-server"?
> Correct. The version of Mach that NeXT computer grabbed was just a copy
Hmmm... not sure what you are claiming is "correct" here:
- NeXT derived from Mach 2.5
- NeXT being contemporary with bsdss
- *or* NeXT being a multiserver?
> of BSD Unix with Mach system calls hacked into it. Mach didn't get
> really interesting until Mach 3 -- the first version where they took the
> Unix system calls out, and moved all of the Unix-like services into a
> user-level process.
I'll have to double check but I believe bsdss ran under 2.5
As such, *it* was a "user level process" (BSD Single Server).
bsdss's grief was related to the licensing issue. Also, it
didn't build on the "promise" of Mach -- by allowing "monolithic
kernel comparable performance" (it was just a big emulator
sitting atop Mach). Much like Poe or Mach-DOS, etc.
I believe all of the Mach3 "Un*x" work was done on Mach-US and Mach-UX.
--don
Sam Roberts
Seems to me the questions been answered a few dozen ways and
you're getting crotchety (was that the word you used in your
first post?).
Some RTOSs have protected memory space "tasks", some have shared
memory space "tasks", OSs (both real-time and otherwise) that
have both types of "tasks" often use the terms "process" and "thread"
to distinguish between them.
Besides not thinking Unix can be real-time, what terminology do
you offer that distinguishes between the two types of tasks?
Sam
--
Sam Roberts (s...@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
"News is very popular among its readers." - RFC 977 (NNTP)
George Neuner
>Rhetorically, what are the differences between calls,
>functions, and procedures?
>
Mathematically speaking:
- a "function" is a uniquely specified mapping from a given
range to a given domain. (Note that this does not mean that
the mappings are themselves unique - only the specifications).
- a "procedure" is an iterative chained application of one or
more functions where the range is specified by the first
function to be applied and the domain is specified by the
last.
- a "call" is what the mathematician receives from his/her
spouse when he/she forgets to come home for dinner.
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
LSPB
Jack W. Crenshaw wrote in message <366F6B...@magicnet.net>...
|LSPB wrote:
|>
|> Jack W. Crenshaw wrote in message <366DC0...@magicnet.net>...
[snip] ...
|> The Thread is an enumerated set of sequential instructions presented to a
|> CPU. A Thread means something to the RTOS scheduler. The Thread is
presented
|> to the RTOS scheduler as a frozen CPU state.
|
|That is _PRECISELY_ the definition we've always ascribed to a task. The
|task is the thing that gets switched when a context-switch occurs.
|
|You bring up a good point, though. I do get the idea that the
|introduction of the term, "thread" somehow coincided with the advent of
|OO. Not too sure why; perhaps you can explain.
I am not sure if this is true, but I’ll entertain the supposition... first,
the caveats: AFAIK, IMHO, … ;-)
Why did ADA adopt the English word, Task? Why do OO objects have names like
People, Pipe, and Apple? The use of English words is an attempt to form a
common basis of _understanding_ of intent, use, or behavior. It does not
attempt to describe implementation details.
With objects, we are packaging (oops! I realize I am abusing another ADA
term, which reminds me to ask a question below ;-) up tangibles into
conceptual entities that really do not exist. For example,
class Task
{
int i;
};
does not really do anything, allocate anything, nor is it executable.
However, we have created “something” that requires a conceptual term.
From an OO standpoint, we look for a term that captures what the object is.
Why did ADA adopt Task? This was not an arbitrary decision. This was not an
attempt to describe the frozen CPU state which has little to do with what
the Task is accomplishing. Rather, it was chosen to describe to the
programmer that this is a mechanism for concurrent problem solving, i.e.
perform a task.
When OO architects capture, or wrap the Task concept, they find a “part” of
the resulting Task object that is distinct enough to require a new Term.
Essentially, they discovered a thread of execution (an implementation
detail). A Thread does not describe the Task to the user of the object.
In fact, if the implementation of Task on a different class of machine does
not require a Thread, but still accomplishes the desired behavior, the
object is still a Task. Ahh, the OLD term Task survived and the NEW term
Thread died!
Although we may not be agreeing on terms, I hope we have a common
understanding of what I am describing (the more). I ask then, in the
“pre-Thread-Term” days, what was the term for what I am describing? How does
the following relate to ADA’s Task, Package, Entry, and Rendezvous?
class Task
{
int i; // State Data.
Mutex m; // synchronization object.
void
OSCalledThreadEntry(); // Thread.
Task(); // OS service creation.
~Task(); // OS service deletion.
int
Get(); // Inter-task communication (shared memory).
int
Send(); // Inter-process comminication (protected memory).
};
I ask about the ADA Package because I see it claims that a Package body can
possibly contain other tasks as other packages.
-Lance
Pat Rogers
<snip>
>|> The Thread is an enumerated set of sequential instructions
presented to a
>|> CPU. A Thread means something to the RTOS scheduler. The Thread
is
>presented
>|> to the RTOS scheduler as a frozen CPU state.
>|
>|That is _PRECISELY_ the definition we've always ascribed to a
task. The
>|task is the thing that gets switched when a context-switch occurs.
Yes, that's an Ada* task.
<snip>
>Why did ADA adopt the English word, Task?
The language requirements specification may have used that term --
I'll see if I can find a copy. (It is not without irony in this
context to note that Ada was designed by a Frenchman!:)
>Why do OO objects have names like
>People, Pipe, and Apple? The use of English words is an attempt to
form a
>common basis of _understanding_ of intent, use, or behavior. It
does not
>attempt to describe implementation details.
No, but the concept of a task in Ada* represents an active,
concurrent thread-of-control, and, as such, does represent something
to be actively executed. How that execution is implemented varies
with the underlying OS (or lack thereof). The semantics of the task
construct are well-defined except for those places where they cannot
be -- such as how the underlying virtual machine executes them. On
a machine with several processors, one would expect that tasks would
be executed in parallel, in the sense of the "market" would expect
this to be so (just as the market drives the presence of a garbage
collector in some languages). One would also want to be able
*prevent* that mapping of tasks to processors, for the sake of
inter-task communication performance. The point is that some things
have to be left to the implementation.
<snip>
>Although we may not be agreeing on terms, I hope we have a common
>understanding of what I am describing (the more). I ask then, in
the
>“pre-Thread-Term” days, what was the term for what I am describing?
How does
>the following relate to ADA’s Task, Package, Entry, and Rendezvous?
>
>class Task
>{
> int i; // State Data.
> Mutex m; // synchronization object.
>
> void
> OSCalledThreadEntry(); // Thread.
>
> Task(); // OS service creation.
>
> ~Task(); // OS service deletion.
>
> int
> Get(); // Inter-task communication (shared memory).
>
> int
> Send(); // Inter-process comminication (protected memory).
>};
>
>I ask about the ADA Package because I see it claims that a Package
body can
>possibly contain other tasks as other packages.
A package is a passive module providing visibility control. A task
is an active entity (also with visibility control) and, hence, has
both an interface and a body describing local declarations and the
sequence of statements that is to be executed concurrently with
other tasks. Just as we can have many instances of the above class
Task, we can have many instances if we declare a task *type*.
Task activation and termination under programmer control, but the
implementation handles the details. These activities correspond to
the ctor/dtor above.
"Entries" specify the task interface (or, for a task type, all
objects of the type). As such they define the name of the entry and
any inputs or outputs to be provided, much like procedures. They
are called "entries" (I've always assumed) because they are "entry
points" at which the task is willing to synchronize and communicate
with other tasks. Entries are implemented by "accept" statements
(rather than by procedures as in some languages, such as Concurrent
Pascal). These accept statements are executed just like any other
statement within the tasks' sequence of statements representing the
tread-of-control. When one task calls another's entry, they
eventually "rendezvous", which means they threads are
synchronized -- the caller waits for the corresponding accept
statement to execute, in an essentially client-server model. For
communication, the accept statements may reference input parameters
and provide values via output parameters, much like a procedure
call. The thing to keep in mind is that tasks execute sequences of
statements; intentionally infinite loops, for example, would
represent threads of control that never stop. Some of those
statements implement the entry points and provide services to
callers.
Ada's rendezvous in fact was not revolutionary -- it was
evolutionary; Ada didn't invent the rendezvous concept. The Ada
rendezvous is really best called an "extended rendezvous" because
accept statements can (and usually do) contain nested statements to
provide the service requested. So an entry would correspond to the
inter-task communication you describe above. If the underlying
implementation maps tasks to distinct processes, then an entry would
also correspond to inter-process communication. The parameters of
the entries, however, are the means by which tasks are usually
intended to communicate. Yes, shared memory is easily possible, and
the semantics are defined, but the dangers were well-known and,
consequently, shared variables are not the primary mechanism for
communication. Another thing to note is that other means of
communication are possible, besides entry parameters and directly
shared memory: the sequence of statements might send messages via a
message-passing mechanism, just to name one.
The mistake in the design of Ada 83 was that tasks are indeed
threads-of-control, representing CPU states. If all one needs is
mutual exclusion or condition synchronization (e.g., "buffer full")
then a full task is serious overkill (an example of so-called
"abstraction inversion") and thus represents a performance problem.
To remedy that, Ada 95 has added "protected types", which provide
both mutual exclusion and condition synchronization in an
inexpensive construct. Protected types (and objects thereof) are
*not* threads-of-control, and thus do not have the expense of task
switching inherent in tasks. So if one needs a thread-of-control, a
task is appropriate.
How's that? Did it raise more questions than it answered?
*Ada is named after a person, so it is usually written as such.
That isn't a big deal, but then, if we wrote "Cplusplus" people
would wonder. :-) I'm not sure if it is a good thing or not that
Microsoft celebrates Ada (the person) on their Certificates of
Authenticity! many :-) ...
Aerospace Software
I am of the opinion that the confusing proliferation of different names
for the same things are simply due to all the people doing their
doctorates in computer science, who then need to "invent" something new
in order to justify the degree.
Eg:
a. program, routine, computer software configuration item
b. module, object, program unit, computer software unit
c. subroutine, procedure, method
d. list, structure, object
etc.
Another university, another professor, another set of names and
notations...
Have fun,
Herman
Jack W. Crenshaw
>
> A process is not a thread, and not a task.
> A thread is not a process, and not a task.
> A task is not a thread, and not a process.
>
> A thread is...a step to completion of a task.
>
> Threads, sometimes fibers, may be woven.
> The act of weaving is akin to programming
> in the skill required, which is why it serves
> the purpose of being a common comparison.
>
> A thread is a step, and a step may be many
> instructions chained together. Consideration
> depends upon the granularity of analysis.
>
> A task is...something to be accomplished.
>
> processes and threads. Protected addresses and shared memory
> can exist, and be described, without any notion of processes,
> threads, or tasks.
>
Well. That really clears _THAT_ question up ;-) Now it's clear as mud.
Jack
Jack W. Crenshaw
>
> The reason that terms evolve is because technology evolves. It seems to me
> that when term "task" was coined it was used in conjunction with
> environments like CICS and similar environments which differentiated between
> the time slice in a partitioned environment (as used in multi-programming
> environments) and a given task to be executed within that environment.
>
Nope. The term, "task," comes strictly from a real-time background,
where it has and always did have a very precise, and easily understood
meaning. The only problem I see is that people are entering this area
from other areas, viz., time-share systems and Windows-based systems,
neither of which are real-time in nature, and where the definitions,
like their OS's, seem to be almost deliberately as foggy as possible.
Jack
Jack W. Crenshaw
> Well, from my prespective the discussion has grown old.
> I think many arguemnts have been made that should convince one
> that the trem "threads" is a resonable term in the context
> that they were introduced.
Are you kidding me? The term has never even been _DEFINED_, except in
the most arm-waving terms.
Jack
Jack W. Crenshaw
>
> So embedded programmers need to learn more
> desktop/mainframe type os terminology. It's going
> to spread and take over in the long run.
>
I guess I see it from the other direction, Tom. Seems to me that
programmers coming from the mainframe, time-share and desktop worlds
into the world of embedded, real-time systems, should at least make a
pretense of learning the terminology that goes with it, instead of
dragging along with them a bag full of terms that are inappropriate in
the new context.
Jack
Jack W. Crenshaw
>
> Bill> It seems to me that several people have mentioned that a task
> Bill> has a seperate static base and threads share them.
>
> Jack> I don't know what this means. For a proper definition of a
> Jack> task, see the Ada LRM.
>
> From the ADA LRM
> Section 9: Tasks and Synchronization -- TOC
> [snip]
> (3) A call on a protected subprogram of a protected object, providing
> exclusive read-write access, or concurrent read-only access to shared
> data;
> [snip]
> (8) In addition, tasks can communicate indirectly by reading and
> updating (unprotected) shared variables, presuming the access is
> properly synchronized through some other kind of task interaction.
>
> What is data that is not a shared variables? This is sometimes called a
> static base or global variables. It is a collection of variables that
> don't allow reentrancy; hence the importance to scheduling.
>
Um ... I _STILL_ don't know what all that means, or how it distinguishes
threads from tasks. Your quotes from the Ada LRM, as well as your other
comments, boil down to a simple concept: Tasks sometimes need to share
data. Big surprise.
How they share that data is, to me, immaterial. Whether it is done via
shared memory, passed parameters, mutexes, semaphores, or other
mechanisms is a choice made by either the programmer, or the designer of
the RTOS. Unless it is your contention that tasks use one or more of
these mechanisms, while threads use a different combination, you still
haven't given me a way to distinguish one from the other.
> This has everything to do with the discussion. According to the platform
> available, different OS scheduling models are possible. The variety of
> hardware gives a variety of 'schedulable entities'. Typically OS schedulers
> must be written in assembler, unless the enviroment is interpreted (byte code,
> like Java and Forth). This is necessary to save/restore context and
> manipulate access rights (if possible).
Repeat again what I said above. None of the above revelations either
come as great surprises, or offer a rule for distinguishing between a
task and a thread.
> Ada is sharing data true, however the sharing is synchronized.
Of _COURSE_ it is. So?
Jack
Jack W. Crenshaw
>
> >Jack W. Crenshaw wrote in message <366F6B...@magicnet.net>...
>
> <snip>
>
> >|> The Thread is an enumerated set of sequential instructions
> presented to a
> >|> CPU. A Thread means something to the RTOS scheduler. The Thread
> is
> >presented
> >|> to the RTOS scheduler as a frozen CPU state.
> >|
> >|That is _PRECISELY_ the definition we've always ascribed to a
> task. The
> >|task is the thing that gets switched when a context-switch occurs.
>
> Yes, that's an Ada* task.
Yep. But Jean Ichbiah and company did not by any means invent the term.
It was, in fact, dictated to them by the Ada language requirements
(Steelman), which specified that the language to be developed should
support multi-tasking as part of the language, rather than something
tacked onto it externally, as C programs are turned into tasks today.
In short, the Ada team used the term, "task" because that's the term
used by the customer.
Why did they not also use "threads," "lightweight threads," and
"processes"? Because they were not needed. I think Ichbiah would agree
with me that the term, task, as used in the Ada language definition,
meets the needs of every conceivable situation encountered in a
real-time, embedded system. Which is what Ada was designed for.
...
> A package is a passive module providing visibility control. A task
> is an active entity (also with visibility control) and, hence, has
> both an interface and a body describing local declarations and the
> sequence of statements that is to be executed concurrently with
> other tasks. Just as we can have many instances of the above class
> Task, we can have many instances if we declare a task *type*.
Absolutely right. The Ada package is no different, really, than a C
module. It's simply a way of ... um ... packaging certain related
program elements together. Today, we _MIGHT_ use a class to contain all
related data and procedures into one class. OTOH, a package might also
contain more than one object. It's strictly intended to be a way to
achieve modularity.
> Task activation and termination under programmer control, but the
> implementation handles the details. These activities correspond to
> the ctor/dtor above.
I think maybe what some folks are not understanding is, that Ada
supports tasking in the language itself (possibly using an underlying
RTOS, but also possibly as a "bare machine," stand-alone system. In the
latter case, the "RTOS" would be part of the run-time library.)
Likewise, Ada rendezvous is built into the language, and synchronization
is both assumed and assured. There is no need for such things as
mutexes, because the language takes care of them.
Thanks for the clear and concise explanation. I am not disagreeing,
only hoping to repeat for emphasis. Hope I got it right!
Jack
Ziv Caspi
> Ziv Caspi wrote:
> >
> > This has nothing to do with Windows. The names used by Win32/NT
> > *probably* came (like everything else in Win32/NT ;-) from VMS.
> > Remember - Windows 3.x actually used the term task (and actually
> > claimed it was a cooperative multi-tasking system).
>
> Please repeat after me:
>
> o VMS is not a real-time system
> o Unix is not a real-time system
> o Multics is not a real-time system
> o Windows NT is not a real-time system
> o Windows 95 is not a real-time system
> o Windows 98 is not a real-time system
> o Windows 3.1 is not a real-time system
> o Solaris is not a real-time system
> ...
>
> I guess you get the picture.
>
> Jack
>
>
Sure:
o VMS is not a real-time system
o Unix is not a real-time system
o Multics is not a real-time system
o Windows NT is not a real-time system
o Windows 95 is not a real-time system
o Windows 98 is not a real-time system
o Windows 3.1 is not a real-time system
o Solaris is not a real-time system
...
I guess you get the picture.
Jack
Note, BTW, that
(1) I did not dispute your claim that thread == task
(2) Some RTOSs were mentioned in this thread (task?) that
also refer to threads rather than tasks
(3) I did explain why I moved to the new-and-imroved (in the
usual embrace-and-extend) nomeclature.
--------------------------------
Ziv Caspi
zi...@netvision.net.il
Don Yuniskis
> Tom Maier wrote:
> >
> > So embedded programmers need to learn more
> > desktop/mainframe type os terminology. It's going
> > to spread and take over in the long run.
> I guess I see it from the other direction, Tom. Seems to me that
> programmers coming from the mainframe, time-share and desktop worlds
> into the world of embedded, real-time systems, should at least make a
^^^^^^^^^^^^^^^^^
I think you are assuming that they *are* coming into the world of...
I don't think that is a necessary conclusion. "Threads" (lightweight
processes, etc.) have application in a desktop/mainframe environment
totally oblivious of "embedded systems".
If, for example, you want to write an *efficient* server, it doesn't
take a rocket scientist to realize that fork()-ing 50 copies of the
same "process" is *horribly* inefficient! Each has to maintain it's
own address space, resource allocation, etc. The cost of communicating
between those "processes" (remember, now I'm speaking in the desktop
world) is horribly inefficient -- since any shared data or synchronization
variables have to require crossing one or more protection boundaries
(via the kernel or some other mechanism).
By contrast, putting several "execution agents" (which they will
lter call "threads") within the *same* environment makes "ITC"
(Inter *Thread* Communication) and synchronization an order (or two)
of magnitude faster and easier, etc.
Years ago, you didn't have desktop/mainframe applications that, for example,
had to service 50, 100, 500 HTTP connections (!). Suddenly, when you
have to look at the prospect of fork()-ing 100 copies of "httpd",
you realize you can't realize the *benefit* of a "multi-processed"
(bastardizing "multi-threaded") server simply because the cost of
supporting all of those *processes* and switching among them exceeds
the benefits to be gained (in throughput, etc.) by implementing them!
OTOH, if you have a nice lightweight structure that is efficient
and easy to implement, you can readily spawn 100 threads and service
100 connections simultaneously, etc.
*And*, you are still oblivious to this world *we* call "embedded systems"!
> pretense of learning the terminology that goes with it, instead of
> dragging along with them a bag full of terms that are inappropriate in
> the new context.
--don
Tom Maier
>I guess I see it from the other direction, Tom. Seems to me that
>programmers coming from the mainframe, time-share and desktop worlds
>into the world of embedded, real-time systems, should at least make a
>pretense of learning the terminology that goes with it, instead of
>dragging along with them a bag full of terms that are inappropriate in
>the new context.
You see this as an issue of right and wrong. I see this more
as an issue of what the final outcome is going to be. There are
probably 500 desktop programmers for every embedded
programmer _and_ the desktop hardware and software
tools are being used to create the new high end automation
systems. It used to be that embedded programmers were
mostly EEs who learned to program, but now I think the
field is going towards CSs who are learning to do embedded
(and brining their stuff with them).
You shall be assimulated! Let me install this pentium running
NT into your neck.=-}
Actually, I'm not in the Borg group yet, I still do the low end
and roll my own as I see it necessary. I'm starting to look into
it though because I think it will be the wave of the future
for the higher end stuff to use these desktop systems on the
upper layers. I visited one company that I used to work for
and they had taken out the old 10 MHz 80186 system that I
put in and now they are running the exact same machine
with NT and a rt kernal modification, a 300 MHz Pentium,
Borland C, a touch screen with draggable icons, and a CD
ROM as the boot device. It looks more like an arcade game
than a piece of industrial equipment now.
Tom
Jack W. Crenshaw
>
> *And*, you are still oblivious to this world *we* call "embedded systems"!
Um ... maybe you could explain, to this ignorant, oblivious peasant,
(a) who "we" are,
(b) what world "you" call "embedded systems", and
(c) when did it change?
Jack
Jack W. Crenshaw
>
> Sure:
>
> o VMS is not a real-time system
> o Unix is not a real-time system
> o Multics is not a real-time system
> o Windows NT is not a real-time system
> o Windows 95 is not a real-time system
> o Windows 98 is not a real-time system
> o Windows 3.1 is not a real-time system
> o Solaris is not a real-time system
> ...
>
Thanks. <grin>
> Note, BTW, that
>
> (1) I did not dispute your claim that thread == task
> (2) Some RTOSs were mentioned in this thread (task?) that
> also refer to threads rather than tasks
> (3) I did explain why I moved to the new-and-imroved (in the
> usual embrace-and-extend) nomeclature.
>
Duly noted. Sorry if I shot the messenger.
Jack
Jack W. Crenshaw
>
> You see this as an issue of right and wrong.
No. Let me make that point perfectly clear. It is _NOT_, IMO, a matter
of right or wrong, but a matter of unnecessary obfuscation of what
_USED_ to be a very clearcut matter.
> There are
> probably 500 desktop programmers for every embedded
> programmer _and_ the desktop hardware and software
> tools are being used to create the new high end automation
> systems.
Yes, that's true. What's more, it will probably always be that way.
However, I'm not sure that numbers are the issue. There are probably
500 fast food clerks for every engineer. Does this mean we should let
fast food clerks define engineering terms?
> It used to be that embedded programmers were
> mostly EEs [and physicists -- Jack] who learned to program, but now I > think the
> field is going towards CSs who are learning to do embedded
> (and brining their stuff with them).
There is a very good reason that used to be the case. CS departments of
universities were turning out grads that could not do real-time,
embedded systems software. Some of them had never heard of an
interrupt. I had one Ph.D., CS grad who couldn't read an oscilloscope.
Even when someone hooked it up to the right pins and got the adjustments
stabilized so that he was looking at the pertinent waveforms, he
couldn't interpret them.
I used to work for a major (Fortune 500) aerospace company. We had a
hard and fast rule there: No CS grads, period. We got our new hires
from the ranks, as you suggest, of EE, Physics, and ME. Occasionally a
math major, but only if he was from an Applied Math background (itself a
dying breed).
Your point, that we now have CS grads moving into embedded systems, is
well taken. However, in most areas, when someone moves from one
discipline to another, one takes the time to learn the terminology of
the _NEW_ discipline. Even if it is really an old one. It takes a
certain amount of chutspah for NFL rookies to expect the pros to adapt
to their college playbooks.
Jack