rtems_semaphore_obtain

[Chris Xenophontos]

All,

An update:

We disabled the interrupt in question during the execution of the task, and
re-enabled upon exit.  This was in an attempt to prevent the semaphore from
being generated while the task is executing.  The problem still occurred,
however, after 24+ hours.  Same problem, i.e, interrupt/semaphore does not
register using rtems_semaphore_obtain with a timeout of one second.

Next thing we'll try is using RTEMS4.6.6. --

Anyhow, this discussion is bringing out a lot of valuable information -

thanks
Chris Xenophontos


-----Original Message-----
From: rtems-users-bounces+cxenophontos=hammers.com at rtems.org
[mailto:rtems-users-bounces+cxenophontos=hammers.com at rtems.org] On Behalf Of
Sergei Organov
Sent: Friday, March 23, 2007 12:27 PM
To: Eric Norum
Cc: rtems-users at rtems.org
Subject: Re: rtems_semaphore_obtain

Eric Norum <norume at aps.anl.gov> writes:

> On Mar 23, 2007, at 9:14 AM, Sergei Organov wrote:
>
>
>>
>> Besides, it will allow to get rid of current run-time dispatch of
>> every operation on either mutex or semaphore between kernel mutex and
>> semaphore code, respectively.
>
> Perhaps I misunderstand this statement.

Yes.

>
> The semantics of a strict priority scheduler require that unlocking a
> mutex perform a check to see whether a higher priority task is
> blocked waiting for that mutex -- if so a task switch is required.
> Does your statement imply some either kind of operation?

When you call, say, rtems_semaphore_obtain(), this routine should first
decide, based on current semaphore flags, what particular internal
routine to call, either kernel_semaphore_obtain(), or
kernel_mutex_obtain() (actual RTEMS function names are
different). However, it's actually known at compile-time if program
needs mutex or semaphore, so this dispatch could be eliminated entirely,
provided distinct API routines are to be called for mutexes and
semaphores.

-- Sergei.
_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users