Strictly atomic operations

[Matt Rippa]

Hi Joel and Sebastian,

Thanks for the replies. I'm working on porting our primary mirror control
system to RTEMS. It's difficult to tell why taskLock() was chosen over a
Mutex. Perhaps it was brute force. It's just two lines of code they were
trying to protect (pointer assignments), and there are no higher priority
tasks which could possibly interfere.  I'll stick with your recommendations.

-Matt

On Mon, Jan 23, 2017 at 6:31 AM, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Mon, Jan 23, 2017 at 2:37 AM, Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> Hello Matt,
>>
>> On 20/01/17 20:12, Matt Rippa wrote:
>>
>>> Greetings,
>>>
>>> In VxWorks 5.5 we use taskLock()/taskUnlock() to stop the possibility of
>>> preemption for a critical region of code. This doesn't stop interrupts as
>>> described here: http://www.vxdev.com/docs/vx55
>>> man/vxworks/ref/taskLib.html#taskLock <http://www.vxdev.com/docs/vx5
>>> 5man/vxworks/ref/taskLib.html#taskLock>
>>>
>>
>> there is currently no API function for this.
>>
>>
> I am curious if it is available in newer VxWorks versions or in the SMP
> VxWorks
> build. I always read that routine as disabling preemption which is not
> safe on SMP
> systems.
>
> If that's all it is doing, then you can use rtems_task_mode() to change
> the preemption mode of the thread.
>
> But that isn't supported in SMP RTEMS. A Mutex is preferable.
>
> What is being protected and why was that chosen? Often it is chosen because
> it seems lighter and faster. It certainly doesn't have any resources.
>
>
>
>>
>>> What would be the recommended approach in rtems? Using semaphores would
>>> not prevent a higher priority thread from preempting me.
>>>
>>
>> The thread dispatch disable level used internally would provide the
>> functionality of taskLock()/taskUnlock(). What is your use case for this?
>> Why can't you use a mutex?
>>
>> The Universal Memory Allocator (UMA) of libbsd disables thread
>> dispatching to access the per-processor caches, however, it should be quite
>> rare to have such a use case at application level.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> 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/20170124/26bfc8cc/attachment-0002.html>