Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Product News: ThreadX not just another RTOS....

0 views

Skip to first unread message

David Lamie

unread,

May 3, 1997, 3:00:00 AM5/3/97

Dear comp.realtime subscribers,

I would like to introduce ThreadX, our high-performance real-time kernel
for embedded applications. ThreadX features a picokernel design that
minimizes size and increases performance. In addition, ThreadX has
highly optimized software timers and a completely new technique to
reduce context switching called preemption threshold.

ThreadX is now available on 68K, x86 (including DOS), Hitachi SH, and
MIPS platforms. Additional support for PowerPC, ARM, C30/C40, and i960
are underway and will be ready within this quarter.

Express Logic also partners with virtually every major compiler tool
vendor. We also work closely with other embedded software component
companies to provide solutions for TCP/IP, ATM, Frame Relay, etc.

Perhaps equally important, our products are offered at very reasonable
prices, with source code, and WITHOUT ANY ROYALTIES! Thank you for your
time and please feel free to contact us for more information.

Sincerely,

David Lamie

For more information, contact:

<A HREF="mailto:dla...@expresslogic.com">dla...@expresslogic.com</A>
<A HREF="http://www.expresslogic.com">http://www.expresslogic.com </A>

Luc Perneel

unread,

May 6, 1997, 3:00:00 AM5/6/97

David Lamie wrote:
> In addition, ThreadX has
> highly optimized software timers and a completely new technique to
> reduce context switching called preemption threshold.

Following your website:

"Most multithreading run-time environments offer two solutions to this
thread protection requirement.
1. The first solution is to disable interrupts.
2. Another solution is to disable thread preemption. "

Never heard about priority enheritance?????
This is a far more easy thing for the programmer to avoid such problems.
"preemption treshold" seems to me a complex solution, as the
programmer has to know which thread priorities he wants to disable
the preemption for.

Ken Tindell

unread,

May 7, 1997, 3:00:00 AM5/7/97

In article <336F31...@rtusi.com>, lp...@rtusi.com wrote:
>David Lamie wrote:
>> In addition, ThreadX has
>> highly optimized software timers and a completely new technique to
>> reduce context switching called preemption threshold.
>
>Following your website:
>
>"Most multithreading run-time environments offer two solutions to this
>thread protection requirement.
>1. The first solution is to disable interrupts.
>2. Another solution is to disable thread preemption. "
>
>Never heard about priority enheritance?????
>This is a far more easy thing for the programmer to avoid such problems.
>"preemption treshold" seems to me a complex solution, as the
>programmer has to know which thread priorities he wants to disable
>the preemption for.

I believe it is "preemption threshold TM", not to wantonly violate the
trademark. A much more sophisticated version of this algorithm
was published 20 years ago. The algorithm is generally called the
immediate ceiling priority protocol (ICPP), and can be most accessibly
found described in "Real-Time Systems and their Programming Languages",
by Burns and Wellings (2nd Edition), published by Addison-Wesley,
pp.421-422.

For academics, see also Rajkumar, Sha, Lehoczky, "An Experimental
Investigation of Synchronization Protocols", Proc. 6th IEEE workshop on
Real-Time Operating Systems and Software, p.11-17, May 1989. As far
as I am aware, the earliest publication of the algorithm was in a paper
by Lampson and Redhill in 1980. For a history of the research in this area,
see Audsley, Burns, Davis, Tindell, and Wellings, "Fixed Priority Preemptive
Scheduling: An Historical Perspective", Real-Time Systems 8(3),
pp. 173-198 (1995).

I know of at least one other real-time kernel using ICPP to provide
semaphore locks. Also, the Ada 95 programming language uses exactly
this algorithm to provide concurrency control over what it terms "protected
records" (essentially Hoare-style monitors protected by immediate
inheritance semaphores).

It is sad to see excellent ideas and research get re-invented badly
years later. Did I just hear anyone whisper "Java"?.

Ken

Bill Lamie

unread,

May 8, 1997, 3:00:00 AM5/8/97

> >> David Lamie wrote:
> >> In addition, ThreadX has
> >> highly optimized software timers and a completely new technique to
> >> reduce context switching called preemption threshold.
> >
> >Following your website:
> >
> >"Most multithreading run-time environments offer two solutions to this
> >thread protection requirement.
> >1. The first solution is to disable interrupts.
> >2. Another solution is to disable thread preemption. "
> >
> >Never heard about priority enheritance?????
> >This is a far more easy thing for the programmer to avoid such problems.
> >"preemption treshold" seems to me a complex solution, as the
> >programmer has to know which thread priorities he wants to disable
> >the preemption for.

> > Regards,
> > Luc

Priority inheritance is certainly a technique that can be used by
ThreadX applications to handle priority inversion situations. However,
it is not a technique that will reduce context switches like preemption
threshold can. In fact, just the opposite is true - it adds context
switches.

For example, suppose a lower priority thread owns a semaphore and is
preempted by some very important thread (Context switch 1). When the
important thread attempts to get the semaphore, the lower priority
thread temporarily inherits the important thread's priority so it can
finish up with the semaphore (Context Switch 2). When the lower
priority thread finishes, it's priority is reset back to the original
value and the higher priority thread executes again (Context Switch 3).
In this example, there were three context switches and two priority
changes, which in themselves have the overhead somewhere on the order of
a context switch. Lot's of overhead!

If preemption threshold was used, only one context switch takes place!
Now, you might ask how this is any better than just raising the priority
of the lower-priority task before gaining this semaphore. The big
difference is in overhead. Changing a thread's priority typically
requires work on the order of a context save, while setting the
preemption threshold is basically a variable assignment in the thread's
control block.

I'm not saying that every ThreadX application will use preemption
threshold to regulate preemption, but I am saying that - for virtually
no cost in overhead - it gives application developers another tool to
help them in their real-time design. Also, I should mention that
ThreadX is a real-time kernel for embedded applications. Its design
focus is for deterministic and high-speed operation in limited memory
environments.

> Ken Tindell wrote:
>
> I believe it is "preemption threshold TM", not to wantonly violate the
> trademark. A much more sophisticated version of this algorithm
> was published 20 years ago. The algorithm is generally called the
> immediate ceiling priority protocol (ICPP), and can be most accessibly
> found described in "Real-Time Systems and their Programming Languages",
> by Burns and Wellings (2nd Edition), published by Addison-Wesley,
> pp.421-422.

Right now, I'm trying to check the references you mentioned on Immediate
Ceiling Priority Protocol (ICPP). From just the little information I've
found on the internet so far, there are certainly some similarities to
our
preemption threshold. However, even if the concept is similar, I doubt
that
there is any real-world implementation that is like ours - especially in
terms of low overhead and ease of use.

As for the trademark, this time don't worry about violating the
trademark on
"preemption threshold" - watch out next time though! Just joking -
please
talk about preemption threshold as much as possible! You probably know
this
already, but basically, a trademark is a name or symbol used in
commerce.
Having a trademark is as easy as putting the TM behind it - assuming
that
nobody else is using the name. Some names or symbols used in commerce
have
the R symbol instead of TM. That means that they have been registered
with
the Patent and Trademark office. As you can now see, there is nothing
wrong
with preemption threshold as a trademark. Making a patent on preemption
threshold might prove more difficult since there are similarities with
some
previous work.

> For academics, see also Rajkumar, Sha, Lehoczky, "An Experimental
> Investigation of Synchronization Protocols", Proc. 6th IEEE workshop on
> Real-Time Operating Systems and Software, p.11-17, May 1989. As far
> as I am aware, the earliest publication of the algorithm was in a paper
> by Lampson and Redhill in 1980. For a history of the research in this area,
> see Audsley, Burns, Davis, Tindell, and Wellings, "Fixed Priority Preemptive
> Scheduling: An Historical Perspective", Real-Time Systems 8(3),
> pp. 173-198 (1995).
>
> I know of at least one other real-time kernel using ICPP to provide
> semaphore locks. Also, the Ada 95 programming language uses exactly
> this algorithm to provide concurrency control over what it terms "protected
> records" (essentially Hoare-style monitors protected by immediate
> inheritance semaphores).

I'm not aware of any other commercial kernel that is offering a
preemption
threshold type of service. Don't forget that preemption threshold in
ThreadX is NOT limited to protection of system objects, e.g. queues,
semaphores, memory pools, etc. Instead ThreadX preemption threshold
governs
the entire execution of the thread. I think (could be wrong here) this
is
different than the Ada 95 implementation.

It is also worthwhile to mention that our preemption threshold technique
is
part of each thread's context. That is to say, each thread has its own
unique preemption threshold. In contrast, many commercial products use
a
global preemption lockout flag where all threads are disabled during one
thread's critical section.

> It is sad to see excellent ideas and research get re-invented badly
> years later. Did I just hear anyone whisper "Java"?.
>
> Ken

This statement seems a tad unfair, especially in the context of
preemption
threshold. It is also inconsistent. If you say preemption threshold
is
just like ICCP, then it stands to reason that it is NOT a bad
re-invention,
but instead a very good one!

Bill Lamie
Express Logic, Inc.
bla...@expresslogic.com
http://www.expresslogic.com

0 new messages