3.5Queues

...

16template <class Type> RingBuffer<Type>::~RingBuffer()

17{

18delete [] data;

19}

3.5.2 RingBuffer Member Functions

The member functions IsEmpty() and IsFull() are self-explanatory. Peek(Type & dest) returns QUEUE_FAIL (i.e. nonzero) if the queue is empty. Otherwise, it stores the next item in the queue in dest, but without removing it from the queue. The Peek() function is useful for scanners which usually require a single character look-ahead. Traditionally, a character looked ahead is pushed back into a queue by means of a function unput(char) if the character is not required. But this solution causes several problems. ??? Which problems ??? So providing a look-ahead function like Peek() is the better solution, as it does not remove any item from the queue.

1 // Queue.cc

...

21template <class Type> int RingBuffer<Type>::Peek(Type & dest) const

22{

23int ret = QUEUE_FAIL;

24

25{

26os::INT_MASK old_INT_MASK = os::set_INT_MASK(os::NO_INTS);

28os::set_INT_MASK(old_INT_MASK);

29}

30return ret;

31}

The member function PutItem() inserts, and GetItem() removes an item from the queue. However, PutItem() assumes that the queue is not full when it is called, and GetItem() assumes that the queue is not empty. This condition is not checked, because the check as such is different for queues that use semaphores and queues that do not use semaphores. Apart from that, interrupts are in general to be disabled when these functions are called. To avoid direct usage of these functions, they are made protected so that only classes derived from RingBuffer can use them.

33template <class Type> inline void RingBuffer<Type>::GetItem(Type & dest)

34{

35dest = data[get++];

37count--;

38}

...

40template <class Type> inline void RingBuffer<Type>::PutItem(const Type &src)

41{

42data[put++] = src;

44count++;

45}

Finally, it has shown to be useful to provide polled access to both ends of a queue, even if semaphores are used. For this purpose, the member functions PolledGet() and PolledPut() are used. Their implementation depends on where semaphores are used; thus they are purely virtual.

3.5.3 Queue Put and Get Functions

The polled and semaphore-controlled Put() and Get() for the four possible types of queues result in a total of 12 functions. Rather than explaining them all in detail, we only present the basic principles:

•Interrupts are disabled while the ring buffer is accessed.

•For polled operation, if a semaphore is used at the polled end of the queue, the semaphore is polled as well in order to keep the semaphore synchronized with the item count.

•It is always checked if the queue is full before PutItem is called, and if the queue is empty before GetItem is called. This check is explicit if no semaphore is used at the respective ends, or implicit by polling the semaphore.

3.5.4 Queue Put and Get Without Disabling Interrupts

In the implementation shown, the manipulation of the queue is always performed with interrupts enabled. Considering the short code, this causes a significant overhead. Often interrupts are already disabled anyway, e.g. in interrupt service routines. In those cases, one can derive other queue classes from RingBuffer that do not disable interrupts.

It should also be noted that the get and put ends of the queue are more or less independent of each other. As we have seen in PutItem() and GetItem(), the count is always modified after putting or getting an item. If incrementing or decreasing count is atomic (which is the case for most compilers), and if there is only one task or interrupt service routine at all (which is the case for most queues), then it is not necessary at all to disable interrupts. It may as well be the case that interrupts need to be disabled only at one end of a queue, e.g. for one task that receives messages from several other tasks. A good candidate for such optimizations are the character input and output queues for serial I/O.