<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 11:25 AM, Matt Rippa <span dir="ltr"><<a href="mailto:mrippa@gemini.edu" target="_blank">mrippa@gemini.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Joel and Sebastian,<div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>The taskLock in that case would make the update of the two pointers</div><div>atomic (duh) but there would be no concern over the users of those</div><div>pointers. </div><div><br></div><div>With a mutex, I think you would have to have locking code when the </div><div>pointers are dereferenced to ensure they are in a consistent state.</div><div><br></div><div>I have no idea how much code this impacts but it impacts code which</div><div>is operating with no idea that it needs to honor an atomic update of</div><div>that data.</div><div><br></div><div>I would be prone to take a few minutes to figure out what the overall</div><div>intent is and how frequently those pointers are dereferenced. The update</div><div>of the pointers must be coordinated.</div><div><br></div><div>Since you are on a single CPU system, you could get by with NO_PREEMPT</div><div>temporarily. But it would be much better to understand the interaction and </div><div>find an SMP safe solution.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div></div><div>-Matt</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 23, 2017 at 6:31 AM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jan 23, 2017 at 2:37 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brai<wbr>ns.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Matt,<br>
<br>
On 20/01/17 20:12, Matt Rippa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings,<br>
<br>
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: <a href="http://www.vxdev.com/docs/vx55man/vxworks/ref/taskLib.html#taskLock" rel="noreferrer" target="_blank">http://www.vxdev.com/docs/vx55<wbr>man/vxworks/ref/taskLib.html#t<wbr>askLock</a> <<a href="http://www.vxdev.com/docs/vx55man/vxworks/ref/taskLib.html#taskLock" rel="noreferrer" target="_blank">http://www.vxdev.com/docs/vx5<wbr>5man/vxworks/ref/taskLib.html#<wbr>taskLock</a>><br>
</blockquote>
<br>
there is currently no API function for this.<br>
<br></blockquote><div><br></div></span><div>I am curious if it is available in newer VxWorks versions or in the SMP VxWorks</div><div>build. I always read that routine as disabling preemption which is not safe on SMP</div><div>systems. </div><div><br></div><div>If that's all it is doing, then you can use rtems_task_mode() to change</div><div>the preemption mode of the thread.</div><div><br></div><div>But that isn't supported in SMP RTEMS. A Mutex is preferable.</div><div><br></div><div>What is being protected and why was that chosen? Often it is chosen because</div><div>it seems lighter and faster. It certainly doesn't have any resources.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What would be the recommended approach in rtems? Using semaphores would not prevent a higher priority thread from preempting me.<br>
</blockquote>
<br>
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?<br>
<br>
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.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brain<wbr>s.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br></span>
______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/users</a><br>
</blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>