sung@ceco.ceco.com (Sung Han) (04/18/91)
Hello, fellow real-time developers!
I'm doing an evaluation of the latest real-time networked kernels for MC680x0
based boards, and I'd like some opinions from people who have used any of the
following OS packages for a significant period of time:
pSOS+ (w/ pROBE+, pREPC+, pNA+, etc.)
VRTX (VRTX32 w/ VRTX Velocity)
VxWorks (version 5.0 or similar, w/networking & X-windows)
Uniflex
I'm particularly interested in the kinds of insights that I wouldn't be able to
get in a 30-day perusal of the packages, which is what I'm doing now. If you
have any strong opinions about any of these products, I would appreciate it if
you could e-mail me your thoughts. I would prefer that you not post a follow-up
in this group, as I don't want to start a "this kernel stinks" or "this OS is
better than that other OS" kind of thread in here.
Thanks in advance.
------------------------------------------------------------------------------
sung@ceco.ceco.com
or
uunet!ceco.ceco.com!sungempty@polari.UUCP (Terry Peterson) (04/25/91)
I've just read through the Draft 1003.4a/D5 Dec 7, 1990 and am confused (or
perhaps just uncertain) on a couple of points:
In section 4.5.1.6.1 Mutex Scheduling Attributes (page 50) there is a
discussion of priority ceilings as a mutex-specific scheduling policy.
Per-mutex scheduling policies are unfamiliar to me so don't assume I know
enough to even ask this particular question without confusing everyone.
Anyway, line 243 says that "...each mutex has a priority ceiling, defined as
the priority of the highest priority task that can lock the mutex. A mutex
can be locked only if the thread which requests the lock has a higher priority
than the priority ceilings of all currently locked mutexes."
I interpret these two sentences to establish the following semantics:
a) Let TP equal the priority of the thread attempting to lock a mutex.
b) Let PC equal the priority ceiling of the mutex.
c) Let HPC equal the highest priority ceiling of the current set of locked
mutexes.
(1) For ( TP > PC ):
The lock attempt fails. If this is the case, what are the semantics of
failure. I presume the thread blocks (see, for example, line 330, p 53).
However, if such is the case, then isn't it possible to have the rather
incongruous situation of an unlocked mutex at which a host of high
priority threads are blocked?
(2) For ( HPC < TP <= PC ):
The lock attempt succeeds.
(3) For ( TP < HPC )
The lock attempt fails. Again, as in the first case, what are the failure
semantics.
For ( PC < HPC ):
No mutex whose priority ceiling is less than HPC can be locked no matter
what the priority is of the thread attempting the lock. Said another way,
only mutexes whose priority ceilings are greater than the current HPC may
be locked.
In general, if I've interpreted those two sentences correctly then my
uncertainty only lies in the behavior of threads who fail to lock a mutex
because they violate one or more of the scheduling policies predicates.
Thanks, in advance for any light one or more of you may shed on this issue.
/t