Hi,
I'd be very grateful if you could confirm the following questions:
1) I understand that in Orocos both attributes and properties are executed on the caller thread. Debugging their getters and setters, I haven't seen any mutex code. So, I understand it's not thread safe to modify their values, even from their owner TaskContext thread, right? Is there any way to make them thread-safe? Are they safe-thread when using them from scripting? If there isn't, I understand that the thread-safe way for communicating data which changes amongst TaskContext is through DataFlow port.
2) I understand that the same happens with the Command completion (done) function. It is executed on the caller thread, whereas typically it will have to share access to a flag with the updateHook() method, which will run on the TaskContext's thread. In this case, adding a mutex is easier. For instance, I understand that orocos-apps-checkout/examples/task-intro/PeriodicTaskContext.hpp countTo command is not thread safe, because it accesses the counter attribute from the countTo method and state Machine (own TaskContext thread), and the hasReached function (from the caller thread). Is that right?
thanks
thread-safe: attributes, properties and command completion condi
On Tuesday 28 October 2008 18:35:49 orocos [..] ... wrote:
> Hi,
> I'd be very grateful if you could confirm the following questions:
>
> 1) I understand that in Orocos both attributes and properties are executed
> on the caller thread. Debugging their getters and setters, I haven't seen
> any mutex code. So, I understand it's not thread safe to modify their
> values, even from their owner TaskContext thread, right?
That depends on your system. First of all properties and attributes are not
guarded with mutexes because
1. properties should only be set when you are configuring your component (it's
not running, so no thread safety danger.)
2. attributes should only be used between your updateHook()-alike functions
and your program script, running in the same component (ie in the same
thread).
There are corner cases which are thread-safe anyway: the basic C types int,, std::string or any other struct
float, double,... are all thread-safe (reading/writing) on pentium or newer
Intel-like processors. std::vector
are not.
> Is there any way
> to make them thread-safe? Are they safe-thread when using them from
> scripting? If there isn't, I understand that the thread-safe way for
> communicating data which changes amongst TaskContext is through DataFlow
> port.
Yes. between components: ports. Inside the component (ie same thread) the
attributes and properties are OK.
>
> 2) I understand that the same happens with the Command completion (done)
> function. It is executed on the caller thread, whereas typically it will
> have to share access to a flag with the updateHook() method, which will run
> on the TaskContext's thread.
Correct observation. The completion condition is not thread safe. This does
not mean you *must* use a mutex, but in complex cases, you most likely will.
> In this case, adding a mutex is easier. For
> instance, I understand that
> orocos-apps-checkout/examples/task-intro/PeriodicTaskContext.hpp countTo
> command is not thread safe, because it accesses the counter attribute from
> the countTo method and state Machine (own TaskContext thread), and the
> hasReached function (from the caller thread). Is that right?
Because it's an int, and you run it on a pentium-class processor, it's
thread-safe anyway. For just reading or writing a simple variable, mutexes
are on most systems not needed.[*]
Peter
[*] cases like "i++" from two threads is never thread safe of course.
thread-safe: attributes, properties and command completion condi
Hi,
thank you for the description about the thread-safe use of attributes and properties. It could be useful to add it to the orocos documentation explicitly.
>There are corner cases which are thread-safe anyway: the basic C types int, float, double,... are all thread-safe (reading/writing) on pentium or newer Intel-like processors. std::vector, std::string or any other struct are not.
Hi, do you know where can I find information on which processors ensure this atomicity? After I read this "http://www.ddj.com/cpp/210600279;jsessionid=KHDU55RQGRGZOQSNDLRSKH0CJUNN2JVN?pgno=3" from Herb Sutter, I never trusted atomicity even for single word base types, since it might be that they are not aligned in memory.
best regards
thread-safe: attributes, properties and command completion condi
On Monday 03 November 2008 18:15:47 orocos [..] ... wrote:
> Hi,
> thank you for the description about the thread-safe use of attributes and
> properties. It could be useful to add it to the orocos documentation
> explicitly.
>
> >There are corner cases which are thread-safe anyway: the basic C types
> > int, float, double,... are all thread-safe (reading/writing) on pentium
> > or newer Intel-like processors. std::vector, std::string or any other
> > struct are not.
>
> Hi, do you know where can I find information on which processors ensure
> this atomicity? After I read this
> "http://www.ddj.com/cpp/210600279;jsessionid=KHDU55RQGRGZOQSNDLRSKH0CJUNN2J
>VN?pgno=3" from Herb Sutter, I never trusted atomicity even for single word
> base types, since it might be that they are not aligned in memory.
Thanks for this link ! The articles of Herb Sutter are always an interesting
read. I was aware of the problems posted in this article, and we're using
compare-and-swap (and atomics) as a memory barrier. I hadn't checked
allignment yet, but the unit stress tests could not discover a race yet in
the current implementation (up/smp).
The follow-up article with an alternative implementation[1] is interesting as
well. The basic idea is to use (spin-)locks anyway in combination with
heap-based allocation and padding to avoid cache races. The latter looks a
bit drastic, sacrificing 5 full cache lines for each queue in the
system...someday the compiler should solve this.
As I told before on this list, for big lists and queues, a lock-based solution
is more efficient than the current lock-free implementation we have now. It's
bound to change some day.
Peter
[1] http://www.ddj.com/architect/211601363
thread-safe: attributes, properties and command completion condi
On Tue, 28 Oct 2008, orocos [..] ... wrote:
> 1) I understand that in Orocos both attributes and properties are
> executed on the caller thread. Debugging their getters and setters, I
> haven't seen any mutex code. So, I understand it's not thread safe to
> modify their values, even from their owner TaskContext thread, right?
Properties and attributes should be small, so their setting/getting should
be possible as an atomic operation. Properties and attributes should best
be set by the same activity that runs the code that is influenced by the
properties.
> Is there any way to make them thread-safe?
If thread-safety is important (and it should, in any system of more than
trivial complexity), use a Data Port! This should be the rule of thumb, for
any code that wants to influence other code, without being sure that both
pieces of code are collocated.
> Are they safe-thread when using them from scripting? If there isn't, I
> understand that the thread-safe way for communicating data which changes
> amongst TaskContext is through DataFlow port.
Indeed :-)
> 2) I understand that the same happens with the Command completion (done)
> function. It is executed on the caller thread, whereas typically it will
> have to share access to a flag with the updateHook() method, which will
> run on the TaskContext's thread. In this case, adding a mutex is easier.
> For instance, I understand that
> orocos-apps-checkout/examples/task-intro/PeriodicTaskContext.hpp countTo
> command is not thread safe, because it accesses the counter attribute
> from the countTo method and state Machine (own TaskContext thread), and
> the hasReached function (from the caller thread). Is that right?
>
I think it is. (But Peter can answer more concretely, since he knows the
code best...)
Herman