rtems_semaphore_obtain

[Till Straumann]

I am unable to confirm your problem on the powerpc 'beatnik' BSP
(derived from powerpc/shared AKA motorola_powerpc) on a MVME6100
board. My RTEMS version is the head of the 4.7 branch as of 2007/1/10.

I modified threaddispatch.c so that it asserts a hardware interrupt
line from the code section you claim causes problems:


****** VVVVVVVVVV code added ********
      /* remember thread that was just suspended */
      suspended = executing;
*************************************

      executing = _Thread_Executing;

       _ISR_Disable( level );         -----+
                                           |  Region where
    }                                      |  an occuring 

**** VVVVVVVVVVVVV lines added ********

    /* raise interrupt if the suspended thread matches
     * the specific one stored in 'debug_thread'
     */ 
    if ( debug_thread && debug_thread == suspended )
        raise_hardware_interrupt();

**** ^^^^^^^^^^^^^ ********
                                           |  interrupt
     _Thread_Dispatch_disable_level = 0;   |  causes problems
                                           |
     _ISR_Enable( level );            -----+



before obtaining the semaphore I set

      debug_thread = _Thread_Executing; 

so that the interrupt will be raised from the critical section
when the task obtaining the semaphore is suspended.

The ISR then releases the semaphore.

Everything works normal for me. I used the calls for creating,
obtaining and releasing the semaphore verbatim from your post.


-- Till



Johan Zandin wrote:
> 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
> -----------------------------------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>