rtems_semaphore_obtain

[Johan Zandin]

We have recently detected a problem with semaphores that may be the same
as the one being discussed on the rtems-users list. The initial symptoms
was that a task waiting for a simple binary semaphore sometimes was left
waiting forever. We have now managed to repeat it under controlled
condition in a simulator in the following way:

Create a semaphore like this:

          rtems_semaphore_create (rtems_build_name ('B', 'S', '0', '4'),
                                  0,
                                  RTEMS_LOCAL                   |
                                  RTEMS_SIMPLE_BINARY_SEMAPHORE |
                                  RTEMS_NO_INHERIT_PRIORITY     |
                                  RTEMS_NO_PRIORITY_CEILING     |
                                  RTEMS_FIFO,
                                  RTEMS_NO_PRIORITY,
                                  &Bc1553_S);

Let a task waited for the semaphore in the following way:

      rtems_semaphore_obtain (Bc1553_S, RTEMS_WAIT, 2);

During that call, let an ISR signal the semaphore like this:

      rtems_semaphore_release (Bc1553_S);


When gradually skewing the delay between the rtems_semaphore_obtain call
and the interrupt, we experienced various kinds of problems (illegal
memory accesses, crashes, hanging tasks etc.) whenever the interrupt
occurs in the protected region just after the task switch from the
waiting task to the new heir. See the following excerpt from
threaddispatch.c (from RTEMS 4.5.0):

       _Context_Switch( &executing->Registers, &heir->Registers );

       executing = _Thread_Executing;

       _ISR_Disable( level );         -----+
                                           |  Region where
    }                                      |  an occuring 
                                           |  interrupt
     _Thread_Dispatch_disable_level = 0;   |  causes problems
                                           |
     _ISR_Enable( level );            -----+


We can recreate the problem at least for RTEMS 4.5.0 and RTEMS 4.6.2,
both built for the SPARC processor ERC32.

Changing the timeout value or changing it to RTEMS_NO_TIMEOUT does not
help, so it seems like the watchdog handling is not involved.

Changing semaphore attributes from RTEMS_FIFO to RTEMS_PRORITY or from
RTEMS_SIMPLE_BINARY_SEMAPHORE to RTEMS_COUNTING_SEMAPHORE does not help,
so it seems like the problem is not related to the choice of mutex or
real semaphore.

(Suprisingly enough, changing from RTEMS_SIMPLE_BINARY_SEMAPHORE to
RTEMS_BINARY_SEMAPHORE seems to help. But since signalling of such
semaphores from an ISR to a task are told to be forbidden, I don't
really know what conclusions to draw from that.)

Hopefully, this will help the people with detailed knowledge of the
RTEMS internals to find the cause of the problem...

Best regards
/Johan Zandin

-----------------------------------------------------------
Johan Zandin                      Software Engineer
Saab Space AB                     Phone: +46-31-735 41 47
SE-405 15 Gothenburg, Sweden      Fax:   +46-31-735 40 00
-----------------------------------------------------------