cxenophontos at hammers.com
Fri Mar 23 17:56:02 UTC 2007
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 -
From: rtems-users-bounces+cxenophontos=hammers.com at rtems.org
[mailto:rtems-users-bounces+cxenophontos=hammers.com at rtems.org] On Behalf Of
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.
> 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
rtems-users mailing list
rtems-users at rtems.com
More information about the users