Problem when suspending a task.

[Joel Sherrill]

On 01/07/2010 04:00 AM, Nick Thomas wrote:
>
>    
>> -----Original Message-----
>> From: Eric Norum [mailto:wenorum at lbl.gov]
>> Sent: 06 January 2010 19:53
>> To: Nick Thomas
>> Cc: rtems-users at rtems.com
>> Subject: Re: Problem when suspending a task.
>>
>> Yep, RTEMS provides lots of options.
>> This happens to be one that fits in the category of, "just because you
>> *can* do something it doesn't mean that you "*should*" do something"..
>> ;-)
>>
>> There may be times when it's appropriate to suspend/destroy another
>> task, but you have to take into consideration all the possible side
>> effects of doing so.
>>
>>
>> I hope that this doesn't overly complicate your application.
>>      
>
> I presume that it is safe for task 'X' to suspend task 'Y' when 'Y' is
> asleep, or waiting on a message Q.
> And possibly when waiting on a semaphore.
>    
You can suspend a task at any time.  But there are side-effects.
It is it waiting on a semaphore or message queue, it WILL eventually
receive the resource but will be suspended.  So it could be holding
a message to be processed or a mutex and be suspended.

The suspend state is additive.
> So, is it possible to obtain the state of the task to be suspended, and if
> it's in one of those states then I can suspend it.
> I see that the task state is listed in the monitor 'task' command, but this
> code is in RTEMS, and I can't see an obvious rtems_task_xxx API call to
> obtain this info. Is there one?
>
>    
info calls were not defined in the original RTEID/ORKID API.
It is a shame.  It is an area that we really need more of.  Some
info type calls have been added over the years.  I added
rtems_task_self() not all that long ago.

rtems_task_get_state( id, &state )?

Comments?

But this won't make suspend any safer because as soon as
you get the state, it could change.  And it doesn't tell you
if the task has a mutex.
> Regards
>
> Nick
>
>
>    
>> --
>> Eric Norum
>> wenorum at lbl.gov
>>
>>      
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>