Strictly atomic operations
joel at rtems.org
Tue Jan 24 18:26:21 UTC 2017
On Tue, Jan 24, 2017 at 11:25 AM, Matt Rippa <mrippa at gemini.edu> wrote:
> 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.
The taskLock in that case would make the update of the two pointers
atomic (duh) but there would be no concern over the users of those
With a mutex, I think you would have to have locking code when the
pointers are dereferenced to ensure they are in a consistent state.
I have no idea how much code this impacts but it impacts code which
is operating with no idea that it needs to honor an atomic update of
I would be prone to take a few minutes to figure out what the overall
intent is and how frequently those pointers are dereferenced. The update
of the pointers must be coordinated.
Since you are on a single CPU system, you could get by with NO_PREEMPT
temporarily. But it would be much better to understand the interaction and
find an SMP safe solution.
> 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:
>>>> 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 on SMP
>> 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
>> 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