Strictly atomic operations
joel at rtems.org
Mon Jan 23 16:31:52 UTC 2017
On Mon, Jan 23, 2017 at 2:37 AM, Sebastian Huber <sebastian.huber at embedded-
> Hello Matt,
> On 20/01/17 20:12, Matt Rippa wrote:
>> 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
> there is currently no API function for this.
I am curious if it is available in newer VxWorks versions or in the SMP
build. I always read that routine as disabling preemption which is not safe
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users