Strictly atomic operations

[Joel Sherrill]

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
pointers.

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
that data.

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.

--joel


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