Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v20/repdir/1003.4.033

Internet Message Format | 1990-08-02 | 14KB

From [e-mail]  Thu Jun 21 18:02:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26744; Thu, 21 Jun 90 18:02:29 -0400
Posted-Date: 21 Jun 90 19:57:52 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11487; Thu, 21 Jun 90 17:02:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18902; Thu, 21 Jun 90 16:37:43 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 19:57:52 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>
From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions

John Gertwagen <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

1.  Administrivia

P1003 met in Salt Lake City this time.  Actually, it was at Snowbird
Lodge, south of and well above the city.  It was spring in Salt Lake
but still winter in the mountains.  (Wish I skied.) The real-time
meetings drew 68 people the first day, and averaged around 40 all
week.  If some skiers hadn't deserted each day, we would have had
more.

2.  .4 Balloting

Over 200 people joined the balloting group for P1003.4, Draft 9.  The
first ballot closed in mid-March and 75% of balloters returned their
ballots within a day or two of the official deadline, setting a new
record!  43% of these voted ``Yes'' on the first round, about average
for POSIX ballots.

Lack of time and logistics problems meant little ballot feedback by
meeting-time, (shame on those who didn't submit their ballots
electronically!) but a few issues surfaced.  Several objected to
having binary semaphores only in the path namespace and not also in
shared memory, where they could use simple test-and-set calls, and not
time-consuming system calls.  There's value providing a common
interface for both of these and for other ``synchronization objects.''

There were also objections to having ``events'' when there are
``fixed'' signals in System V, Release 4.  The technical reviewer for
events will try to make SVR4 signals meet real-time requirements.
(Not too long ago, there were strong objections to changing signals.
There may still be protests over adding real-time-required
determinism.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 2 -

3.  Current Work

With .4 in limbo, the working group got on with Threads (.4a),
Language Independent Bindings (.4b), and Real-time Application
Environment Profiles (.14).  Threads got the most attention.
(Surprised?) Despite this, or perhaps because of it, the other two
drafts saw significant progress.

Rick Greer has reviewed a lot of the threads work, so I'll briefly
mention what's going on in .4b and .14, give you some personal views
on threads, and then amplify on areas where our editor, Jeff Haemer,
was recently raked over the coals.

4.  AEP

At first, the real-time AEP small group had some trouble focusing.
They've identified two fairly easy targets, essentially minimum and
maximum configurations, and now seek proposals for intermediate
specifications.

In Utah, the group came up with a fairly complete specification for
embedded systems, and reviewed it with P1003.0 --  the POSIX Guide
group that is the driving force in defining AEP's.  One interesting
issue surfaced during the review: for embedded systems, the AEP group
wants to exclude interfaces of .4 and .1 that aren't needed!  Dot zero
hadn't thought of that before.  Resolving this should set an
interesting precedent.

5.  Language-Independent Bindings

The people doing this have it down to a science, so the large group
has largely left them alone.  Most of their work is converting things
to ``normal'' form, which is mostly tabular, and throwing away the
stuff that is language-dependent.  They made good use of their time,
cranking through a good bit of the .4 draft.

6.  Threads (P1003.4a)

The meeting saw two new proposals.  Both suggested fruitful changes to
the current Pthreads work, but neither was accepted as a new base for
the current draft.

John Zolnowsky of Sun Microsystems submitted one counter-proposal,
called ``strands'' because ``threads'' was already taken.  It was an
attempt to limit the scope of the interfaces and keep thread semantics
closer to process semantics.  Thus, it would have done away with
mutexes and conditions, leaving synchronization to be accomplished
through .4 binary semaphores, presumably modified to have inter-

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 3 -

thread, not just inter-process semantics.  It also proposed more
process-like exit semantics and a version of per-thread signaling.
The consensus on the strands proposal seems to have been that it was
too minimal.

In contrast, the VP (Virtual Processor) proposal, by Paul Borman of
Cray Research, proposed significant ``incremental'' functionality in
the form of a lower-level, virtual-processor interface for use by the
multi-processing and parallel processing communities.  (For those
familiar with Mach, it is roughly to Pthreads as cthreads is to
Cthreads.) Features of the VP proposal included:

   + fork() and exec() semantics for VPs

   + per-VP signal semantics

   + locks and events for synchronization

   + no ordering or scheduling constraints

The group had several concerns about VP

   + Could it support real-time requirements without ordering and
     scheduling constraints?

   + Could the Pthreads constraints be implemented on top of a layer
     that didn't support them?

   + Would the interfaces be used by applications or by system
     implementors?

   + Would an application using both Pthreads and VP interfaces
     encounter analogous problems to those caused by read()s and an
     fread()s on the same file?

   + Would standard interfaces for locks and events, implemented in
     hardware on many systems, constrain or encourage hardware
     development?

   + Would the standard benefit either the user or vendor community?

   + How soon could the proposal be completed and gain enough of the
     MP community's consensus to go to ballot?

Perhaps the deciding factor, though, was that the multi-processing AEP
group (P1003.16) started meeting officially at Snowbird.  [Editor:
Watch for the snitch report, coming soon.] A majority of our group
(including me) felt that MP-specific standards should grow from
requirements identified by .16, not be created on the fly by the
real-time working group.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 4 -

In areas that are still not pinned down, the group made progress
towards a better-defined cancellation mechanism, towards a ``signals
compromise'' that improves on one hurriedly forged at the previous
meeting, and towards more process-like exit semantics.  The consensus
was that we should try to accommodate and specify per-thread signal
state.  Although there are a few strong supporters, a majority did not
feel that specification of per-thread signals is essential to a
standard.

Paul Borman of Cray Research will present a proposal on this at the
next meeting.  I'll be interested to see what Paul comes up with.
With three state elements, (mask, pending signals, and action vector)
and at least three signal delivery types (one, some, all), I can
create many implementation models and corresponding application
architectures.  It may prove easy to construct a plausible model, but
hard to construct one that 40 engineers can agree to live with for a
long time!  I suspect a portable application can assume nothing more
than ``exactly one signal gets delivered exactly once to exactly one
handler.'' (Looks an awful lot likes signals to a process, doesn't
it?)

The biggest progress in the meetings was wide consensus achieved for
the current threads proposal.  The working group resolved many of the
remaining threads issues, and we let Bill Corwin tell IEEE/ISO that we
expect to ballot P1003.4a in July, after the next meeting.

7.  OSF and UI Cooperating?

Our editor's recent editorial stirred up a hornet's nest.  (It wasn't
so much what Jeff said as what he implied.) In his follow-up posting,
he said I'd speak about the joint meetings in more detail.  I didn't
really want to but he twisted my arm, so here goes.

The UI MP Working Group and OSF have been cooperating since the middle
of last year.  I happen to work for a company that belongs to both,
INTERACTIVE Systems Corporation, and though I haven't been to all of
the joint meetings, I've attended them off and on since last November
(which is I think, when they started).  Those I have attended focused
on finding solutions to interface/semantic problems that both OSF and
UI can endorse and that P1003.4 would probably endorse as well.
Although these meetings haven't been advertised I've seen at least one
article about OSF/UI/ATT negotiations that mentioned their cooperation
in the MP arena.  And the meetings have been open.  At least one non-
member has shown up uninvited, and was not asked to leave.

Now, it's no secret that several Pthreads-proposal initiators
(instigators?) work for OSF sponsors.  Since the Pthreads-proposal was
advanced before OSF adopted Mach, it's hard to say whether OSF
influenced the P1003.4 work or the other way around.  Also, in several
instances, OSF/UI members have voted personal opinions contrary to the
OSF/UI consensus established at the joint meetings.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 5 -

What's the point?  The joint meetings contribute to the quality of the
..4a work, but they don't drive it.  I think the work in P1003.4 is
pushing vendors to find multi-threading solutions faster than they
would have on their own.  It's an example of POSIX pushing emerging
technologies, not just creating standards.  There's even a chance that
..4a will create a standard multi-threading interface before millions
of installed, heterogeneous systems force the standard to a lowest
common denominator or to incorporate a particular implementation's
garbage.

And POSIX is playing another role  --  uniting the industry.  I
believe Sun's tooth-and-nail fights with AT&T in P1003.1 led to their
current cooperation.  Maybe the collaboration of OSF and UI on threads
will also bring more unity to the industry.

8.  The relationship between .4 and .4a

Despite what some think, the threads small group has never had any
official status.  Interest and participation in the threads effort
goes far beyond the small group, or even the .4 working group into
other POSIX committees.  Some history may clear this up.

Lightweight processes (i.e., threads) have been on P1003.4's list of
potential work items since its formation.  About 3 years ago, the
working group voted not to pursue them because they were not clearly
needed and the technology was not sufficiently mature.

About a year and a half ago, threads resurfaced as an item of interest
to the real-time users, and also to Ada, Transaction Processing, and
RPC working groups.  A small band of ``experts'' went off to draft a
proposal.  Since P1003.4 was an active system-interfaces committee and
the real-time user community wanted a threads proposal, a lot of hard
work culminated last summer in Minneapolis in a threads proposal being
accepted as an additional chapter for the .4 draft.

There are 12 other interface proposals in the .4 draft.  Some have
been mature for nearly two years, (some with broad consensus, others
without), others are still relatively wet behind the ears.  Still, all
the interfaces are relatively complete (sometimes too complete?), and
in November, when it seemed appropriate to send .4 to ballot, At the
Milpitas meeting, the P1003.4 working group decided to include the
threads chapter in the ballot for comment only, and sought and
obtained authorization to turn the threads work into a separate work
item for the P1003.4 working group.

After the Pthreads proposal was accepted into .4, the small group of
people whose primary interest was threads spent all their time on
threads.  Meanwhile many other .4 members time-shared all the other .4

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 6 -

activities.  Because the Pthreads supporters were so focused, they
sometimes seemed like a separate group.  (Some in the small group
might have been surprised to learn they weren't.  It takes a while to
understand the POSIX bureaucracy.) Nevertheless, though they may not
always have appeared to represent the entire working group, the
Pthreads proposal now enjoys wide consensus.  Apparently, the small
group has listened well to the interests of the working group and the
POSIX community.

At Snowbird, there wasn't a threads small group, there were seven of
them!  These small groups examined how the current and the alternative
proposals addressed:

   + thread management

   + synchronization

   + signals/asynch events

   + cancellation

   + thread-specific data

   + re-entrant functions

   + process control

After reviewing all the issues, we discovered a consensus in most of
these areas, and fairly strong agreement on most issues in the three
or four groups that are still needed.  It looks like things are pretty
well on target.

I'm partially responsible for pushing .4a in before .4 was done, so
I'm partially responsible for the process's not always appearing fair
or well organized.  I'll take my share of the blame.  But I'll also
take my share of the credit for progress in a technology that I
believe to be important for real-time and for the entire POSIX
community.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 20, Number 33