thread safety may be broken for OwnThread operations if sequential activity used

[pdima]

I found the case when the promise is broken of OwnThread operations to be called in the thread safe way.

I have a task with sequential activity with OwnThread operations and event ports.

I found I can call OwnThread operations from task browser in the middle of update hook processing data from event port. I'd expect OwnThread operations to be serialized and called only after updateHook returned.

It's caused by SequentialActivity::thread() returning os::MainThread, so when operation is called from the main thread, OperationCallerInterface::isSend() returns false as the current thread matches activity thread even while activity is being triggered from another thread.

I don't know what would be the appropriate fix for this, OperationCallerInterface::isSend() should check the actual active sequential activity thread instead of the default MainThread, but I don't know how to do this in a thread safe way.

Another possible not very nice workarounds:

1. use a dummy thread for sequential activities so it never matches calling thread
2. OperationCallerInterface::isSend() should return true for OwnThread operations of main thread activities

[meyerj]

Yes, I see the problem. This affects the toolchain-2.9 branch only due to the patch introduced in f5e1d78.

I remember that while working on the patch we had a variant where RTT::base::ActivityInterface::thread() was allowed to return a null pointer for all activities where the executing thread cannot be known by design, like for SequentialActivity and SlaveActivity without a master. isSend() would always return true in that case. I am not sure anymore why this approach has been disregarded at the end. Returning os::MainThread in these cases is just a guess, which might be valid for unit tests or if the operation is called from the TaskBrowser, but not in most other applications.