Specwing The Count LimÌt

The interrupt task, when it initially calls SET$INTERRUPI, puts a limit on the maximum number of outstanding SIGNAI-$INTERRUPI requests. The interrupt$taskgflag

parameter specifies this limit. When the inteÍupt handler calls SIGNAIJINTERRUPT, causing the count to be incremenîed to the limit, two events happeri:

. The interrupt level is disabled, preventing the handler from accepting fuÍher interrupts until the interrupt task makes its next WAfr$INTERRUPT or RQE$TIMED$INIERRUm call.

. The E$INTERRUPT$SATURATION condition code is returned by

SIGNAIJINTERRUPf to the handler, indicating that the limit has been rcached.

This is an informative message only.

When the task calls WAIT$INTERRUPT or RQE$TIMED$INTERRUPT and

decrements the count below the limil the imerrupl level is enabled, allowirìg the handler to resume accepting intenupts.

The task should always set the limit €qual to the number of buffers that the task and handler use. If the task sets the limit larger than the number ofbuffers, the handler will accept iflteÍupts when no buffers are available and data will be lost, If the task sets the limit smaller than the number of buffers, there will always be empty buffers and space will be wasted.

For examplg if one buffer is used, the task should set the limit to one, Iù this case, the interrupt level is always disabled while the task is processing the buffer. Iî two buffers are used, the task should set the limit to two. Then, the handler carì fill one buffer while the task is proce.ssing the other. Additional buffers requìre correspondingly higher limits.

However, if the task sets the limit to zero, the interrupt handler operates without an inîerruDt task.

NOTÉ

Whefl an interrupt task sets îhe count limit to oDe, SIGNAIJINTERRUPT will ùot return the

E$INTERRUPX$SATURATION condition code.

Nucleus Uset's Guide 9-19

INTERRUPT MANA.GEMENT

Table 9-4 illustrates the situation described in this section. It shows the actions of the

handler and the task illustrated in Figurc 9-4. The table is broken up into three parts: \v.

actions of the interrupt handler, actions of the inteúupt task, and SIGNAIJINTERRUPT count. The count limit is set to two. The table shows the actions of both the handler afld the îask through timg altd the change in value of the count.

Table 9-4 documents two e{reme conditions, labeled A and B. At position A, the interrupt handler fills its last available buffer and calls SIGNAI$INTERRUPT to notif the task. However, the task has not finished processing the fi.st buffer, so the coùlt is incremented to the limit and interrupts are disabled until the task finishes with the first bùffer and calls WAIT$INTERRUPT.

At positior B, the opposite case exists. The task finishes processing its buffeî and calls WAIT$INTERRUPT. However, the handler has not prccessed enough interrupts to fill a bulfer, so the task must wait until the handler calls SIGNAI-$INTERRUSI.

CaII SET$INTERRUPT to

establish handler and task for lèvè|, setting count limitto2.

Call WAIT$INTERRUPT

to wait for frst requesl from handler lnfpt

ìntnt lntrpt

Process inîerupt, stadflling first buffer, Process idlerupt, continue f lling fksl buJf€r.

Process interupt. Bufier isfull. Call SIGNAL$INTERRUPT.

Process intorupt. Start flling n€xt buff€r.

Process intorrupt. 8uÍer isfull. Call SIGNAL$INTERRUPT. Count is at limit.

Inle.rupl level is disabled.

Table 9-4. Handler and Task Interaction throush Time Interupt

Handler

SIGNAL$

Interupt INTERRUPT

Task Courìt

9-20

---(contin

Nncleus Uset's Guide

9.3.5.4 Enabling hterrupt Levels From Within a Task

Sometimes, an interrupt task may finish with a buffer of data before it finishes rts processing. Al example ol this is a task that processes a buffer and then waits at a

mailbor, possibly for a message from a user terminal, before calling WAIT$INTERRUPT.

If other buffers of data are available to the handler (i.e., the count of outstanding SIGNAL$INTERRUPI requests has not reached the limit), this does nor Dresenr a problem. The handler can continue accepting interrupts and filling empry ùuffers.

However, if the interrupt task is processing the last available buffer (i.e., the coùnt limir has been reached), the interrupt handler cannot accepr further interrupts because the interrupt level is disabled. This may be an ùndesirable situation if the interrurrt task takes a long time before calling \ryAI$INIERRUPT.

To prevent this situation, the inte.rupt task can invoke the ENABLE system call immediately after it processes the buffer, enabling its associated interrupt level. This means that while the task engages in its time-consuming activitieq the inteffupt handler can accept further interupts and place the data into the buffer jùst released by the task.

(You can also use this technique whenever the count limit is one, whether or úot you use a bufîer.)

However, if the interrupt handler fills the buffer and calls SIGNAIJINTERRUpT before the task calls WAII$INTERRUPT, the tb owing events occur:

. The count of outstanding SIGNAIJINTERRUPI requests is incremenred, caùsing it to exceed the user-specified limit,

. An exception code, E$INTERRUPT$OVERFLOW, is returned ro the interupr handler to indicate this overflow.

INTERRUPT MANAGEMENT

Table 9-4. Handler and Task Irtenction úhruugh Time (continued) I Ca||WA|Í$INIERRUPT. 1 I Task starts processing next futì

tJullèr immediatov and r6runs emw bufier. ldt€rupt l6v€l is enabl€d.

InÍpt I Process irìterupt. Siadfitting nen buffer.

CaIIWAIT$INTERRUPT. O No full buffers ar€ available. fask

waits lor n€xt request.

lnfpt I Process inteftupt. Buff6risfull. Catl SIGNAL$INIEBRUPT.

Start processing 1

next full buffer.

Nucleus Usefs Guide 9-21

INTERRUPT MANAGEMENT

. The interrupt level is again disabled. The interrupt task cannot explicitly enable the level again until the count falLs to or below the limit.

If the interrupt task calls DNABLE when the count is below the limit, nothing happens and no exception code is returned. However, if the intemrpt task tries to enable the hterrupt level when the count is greater tha! the limit, the ENABLE system call retums the E$CONTEXT exception code.

If a task other than an interrupt task tries to enable the level, one of three events may occur:

If the level is already enabled, the ENABLE system cail retì.lrns rhe E$CONTEXT condition code.

If the non-interrupt task tries to enable the level (presumably following a DISABLE) and the interrupt task is not running (i.e., the iíte.rupt task has callcd

WAIT$INIERRUPT and is waiting lor a service request), the level is enabled immediately.

If the interrupt task is running, the enable does not take affect until the intenupt task next invokes WAITSINTERRUPT.