intLock() vs. taskLock()

Enrico Ferro

unread,

Nov 19, 1997, 3:00:00 AM11/19/97

to

--MimeMultipartBoundary
Content-Type: text/plain; charset="us-ascii"

Hi guys,

we have an application that requires a time-critic operation to be done
without interruptions. This operation may be quite frequent also, so we
don't want to put much overhead to control it.

VxWorks provides intLock() to disable interrupts and taskLock() to disable
task context switching.

The question is, how long does it take to execute taskLock() and
taskUnlock() every time I have to make my uninterruptable operation? Or,
better still, how many instructions are executed by the two calls? Is it
wise to lock/unlock the context switching?

Thanks in advance to anyone who might reply my questions.

Enrico Ferro
Elsag Bailey Hartmann & Braun S.p.A.
Via Hermada 6, 16154 Genova - Italy
Tel. 0039-10-6586222 --- Fax. 0039-10-6586210
Home 0039-10-6517797
Work E-mail Enrico...@elsag.it
Backup work e-mail address Enrico...@usa.net
Home e-mail clu...@clu.assicomitalia.it

--MimeMultipartBoundary--

Dale Luck

unread,

Nov 19, 1997, 3:00:00 AM11/19/97

to

--MimeMultipartBoundary
Content-Type: text/plain

Hmmm, the intUnlock for the mips chip does not call reschedule. it just
blasts the control reg 0
and returns.

>
> Both intLock & taskLock are very fast & take about the same amount of
time. The only significant hit is that taskUnlock and intUnlock both do
a reschedule; that takes a few usecs. Choose the one to use based on
your needs. It's usually better not to lock interrupts unless you have
to.
>
> We have in the past lamented the lack of an
"intUnlockButDontRescheduleBecauseIKnowIHaventCalledAnySystemRoutines()"
function. That would make intUnlock very, very fast. Maybe it doesn't
fit in the target-based symbol table. ;-)
>

Dale
--MimeMultipartBoundary--

Stan Schneider

unread,

Nov 19, 1997, 3:00:00 AM11/19/97

to

>> Submitted-by enrico...@elsag.it Wed Nov 19 06:52:57 1997
>> Submitted-by: Enrico Ferro <enrico...@elsag.it>
>>

>> The question is, how long does it take to execute taskLock() and
>> taskUnlock() every time I have to make my uninterruptable operation? Or,
>> better still, how many instructions are executed by the two calls? Is it
>> wise to lock/unlock the context switching?

Both intLock & taskLock are very fast & take about the same amount of time. The only significant hit is that taskUnlock and intUnlock both do a reschedule; that takes a few usecs. Choose the one to use based on your needs. It's usually better not to lock interrupts unless you have to.

We have in the past lamented the lack of an "intUnlockButDontRescheduleBecauseIKnowIHaventCalledAnySystemRoutines()" function. That would make intUnlock very, very fast. Maybe it doesn't fit in the target-based symbol table. ;-)

-- Stan

=============================================================================
= = =
= Stan Schneider = email: st...@rti.com =
= Real-Time Innovations, Inc. = Phone: (408) 720-8312 x104 =
= 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 =
= Sunnyvale, CA 94089 = http://www.rti.com =
= = =
=============================================================================

Dale Luck

unread,

Nov 19, 1997, 3:00:00 AM11/19/97

to

--MimeMultipartBoundary
Content-Type: text/plain

> intLock and intUnlock are really quick on the mips implementation. You
> don't need to
> do taskLock if you do intLock.
>
And the reason intUnlock is quick is because it is a very dangerous and
improperly coded routine.
It wipes out the entire contents of the register instead of just hitting
the
master interrupt enable bit.

Dale
--MimeMultipartBoundary--

Dale Luck

unread,

Nov 19, 1997, 3:00:00 AM11/19/97

to

--MimeMultipartBoundary
Content-Type: text/plain

intLock and intUnlock are really quick on the mips implementation. You
don't need to
do taskLock if you do intLock.

Dale

--MimeMultipartBoundary--

Hwa-Jin Bae

unread,

Nov 20, 1997, 3:00:00 AM11/20/97

to

Hi!

Contrary to what's been said by others, intUnlock does do
reschedule (unlike taskUnlock). This is true for all
VxWorks architecture ports that I've used -- 68k, mips, sparc, i960.
It would make no sense to make intUnlock do rechedule anyway.

Fred Roeber

unread,

Nov 21, 1997, 3:00:00 AM11/21/97

to

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ok, lets try to get this straight once and for all. Hwa-Jin was
typing a bit too fast when he tried to explain what happens. On
the first line he should have said "intUnlock does NOT do reschedule".
That is the correct statement and agrees with the last line of his
message. Thus, from a performance perspective (which is where this
thread originally started), locking interrupts is a more efficient
way of protecting a critical section than task locking since
interrupt locking just involves hardware manipulation and task
unlocking requires a pass through the rescheduling code. That said,
there is still the issue that interrupt locking is dangerous. You
make a mistake with interrupts locked, you hang your processor.
Further, interrupt locking directly affects VxWorks responsiveness
and latency at handling things. Lock interrupts too long and hardware
stops working. Still, used carefully, nothing beats interrupt
locking for high performance, short, critical sections. Interrupt
locking is like a sharp knife. It does the job a lot better than
a dull one but can hurt a lot worse if used wrong. Fred

Ken Rowberry

unread,

Nov 21, 1997, 3:00:00 AM11/21/97

to

one thing to look out for in intLock()/intUnlock() is that it doesn't
prevent a reschedule. Many vsWorks calls force a reschedule on
completion. The solution is to be VERY careful which OS calls you make
while in the intLock() block.

...ken

--
Kenneth Lee Rowberry

mailto:rowb...@sdd.hp.com
(619) 655-4584 voice / (619) 655-5750 fax
Hewlett-Packard
M/S 60U360
16399 West Bernardo Drive
San Diego, CA 92127-1899

Stan Schneider

unread,

Nov 25, 1997, 3:00:00 AM11/25/97

to

Oops. I was blew that one. I published too quickly; intLock (at least on PPC where I looked) does not reschedule, only taskUnlock. Sorry about the confusion...

-- Stan