Strictly atomic operations

[Joel Sherrill]

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/20170123/a843f4f7/attachment-0002.html>