deadlock from spinlock waiting..

[Saurabh Gadia]

Please check the timeout value passed to wait() for write task. This is the
only thing I can think of. otherwise the read task should proceed.

Thanks,

Saurabh Gadia

On Sun, Aug 23, 2015 at 2:23 AM, 김찬 <ckim at etri.re.kr> wrote:

>
>
> Hi, Saurabh,
> Thank you for letting me know that. I didn't see the code inside the wait
> function thourougly.
> But my case is still read task holding it and write task waiting for it.
> There must be some other cause for this I guess.
> Thanks!
>
> Chan
> ------------------------------
> *보낸 사람 : *"Saurabh Gadia" <gadia at usc.edu>
> *보낸 날짜 : *2015-08-23 00:00:55 ( +09:00 )
> *받는 사람 : *김찬 <ckim at etri.re.kr>, users at rtems.org <users at rtems.org>
> *참조 : *
> *제목 : *Re: deadlock from spinlock waiting..
>
>
> Ohh, lots of typos. Sorry for that.
>
> As per your case task A has the lock and task B will be waiting for the
> lock. Firstly as per your contex, I take that you are running uniprocessor
> targets. So in CORE_spinlock_Wait routine if the lock is not available and
> if no timeout is providedthen its true that this thread will spin
> indefinitely until it gets the lock. But main question is how will it get
> lock if it disables dispatches and interrupts. I guess your going in right
> direction. But while waiting for the lock it performs following things:
> from corespinlockwait.c
>
>         for(;;)
>         {
>             ...
>             ...
>            _ISR_Enable( level );
>        /* An ISR could occur here */
>
>        _Thread_Enable_dispatch();
>        /* Another thread could get dispatched here */
>
>        /* Reenter the critical sections so we can attempt the lock again.
> */
>        _Thread_Disable_dispatch();
>
>        _ISR_Disable( level );
>         }
>
>   So while waiting task B(write task) gives up the processor periodically
> if lock is not available. So this way your read task will get the control
> from scheduler after write task relinquishes the CPU. Hope this helps.
>
>
> Thanks,
>
> Saurabh Gadia
>
> On Sat, Aug 22, 2015 at 7:56 AM, Saurabh Gadia <gadia at usc.edu> wrote:
>
>> Hi Kim,
>>
>> As per your case task A has the lock and task B will be waiting for the
>> lock. Firstly as per your contex, I take that you are running querying
>> about uniprocessor targets. So in CORE_spinlock_Wait routine if the lock is
>> not available and if provide no timeout for this routing then its true that
>> this thread will spin indefinitely until it gets the lock. But main
>> question how will it get lock if it disables dispatches and interrupts. I
>> guess your going in right direction. But while waiting for the lock it
>> performs following things: from corespinlockwait.c
>>
>>         for(;;)
>>         {
>>             ...
>>             ...
>>            _ISR_Enable( level );
>>        /* An ISR could occur here */
>>
>>        _Thread_Enable_dispatch();
>>        /* Another thread could get dispatched here */
>>
>>        /* Reenter the critical sections so we can attempt the lock again.
>> */
>>        _Thread_Disable_dispatch();
>>
>>        _ISR_Disable( level );
>>         }
>>
>>   So while waiting it gives up the processor periodically if lock is not
>> available. Hope this helps.
>>
>> Thanks,
>>
>> Saurabh Gadia
>>
>> On Fri, Aug 21, 2015 at 11:18 PM, Chan Kim <ckim at etri.re.kr> wrote:
>>
>>> Hello,
>>> This is a very basic question and I guess something's wrong in my
>>> understanding.
>>> I'm trying to use spinlock but not sure if it's working as I intend to
>>> use it for.
>>> The _CORE_spinlock_Wait function seems to be disabling interrupt. the
>>> code brief say even task dispatch is disabled.
>>> Then when task A already has the lock, and task B tries to get the lock,
>>> how can task A release it if it is not dispatched?
>>> My case right now seems like that. (write task waiting for the lock, but
>>> read task has the lock and because interrupt is disabled,  read task cannot
>>> process things..)
>>> I'm uinsg version 4.10.99.
>>> Chan
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150823/aa1db5b6/attachment-0002.html>