[IGSTK-Developers] [IGSTK-Users] (Micron)Tracker update problem

[Patrick Cheng]

Hi Vincent,

Thank you for your suggestion. We will do some testing this week and 
incorporate your feedbacks.

I forgot you are also on the Developers' list as well. My rule for which 
list to send is: If the email contains information that might be helpful 
  to some users, I will cc the users' list, such as this one. 
Developers list is more for internal discussions. They are both publicly 
archived.

Thank you,

Patrick

Vincent Gratsac wrote:
> Hi Patrick,
> 
> Thank you for your answer.
> 
> Actually I modified the Tracker code in order to make the while loop 
> sleeping for some milliseconds, and it resolves my performance problem.
> I think also that setting the MicronTracker single threaded would 
> resolve this problem too. I will confirm it to you in the next days.
> 
> But in my opinion, the best solution would be to modifiy the Tracker 
> code as you suggested in the IGSTK developers mailing list. It would be 
> cleaner than my solution, and multi-threaded. Moreover, it would be nice 
> to let the user modifying the thread refreshing frequency. For example, 
> Claron cameras can only deliver tool's position at a 15Hz frequency...
> 
> Regards,
> 
> P.S : I didn't know to which mailing list I should send this mail...sorry
> 
> Vincent
> 
> Patrick Cheng wrote:
>> Hi Vincent,
>>
>> Can you try comment out line 57 in igstkMicronTracker.cxx
>>
>> this->SetThreadingEnabled( true );
>>
>> This will run the tracker in its default single thread mode.
>>
>> Can you test to see if there is a performance difference? If we can 
>> confirm this, we will consider changing the code to be single 
>> threaded. Also we should probably make the SetThreadingEnabled() 
>> method public instead of protect, so that user can choose.
>>
>> Thank you,
>>
>> Patrick
>>
>> Vincent Gratsac wrote:
>>> Hi all,
>>>
>>> I am currently faced to a "locking" problem when using the igstk 
>>> MicronTracker class.
>>>
>>> This class is multi-threaded :
>>>    - on one side, a separated thread (#1) communicates with the 
>>> tracking system by continuously updating tools informations into a 
>>> buffer (ThreadedUpdateStatus method). This is made in an infinite loop.
>>>    - on the other side, the principal thread (#0) reads informations 
>>> from the buffer at a defined frequency, and affect it to TrackerTools 
>>> objects.
>>>
>>> In order to make this process thread-safe, an Itk MutexLock object is 
>>> used. My problem is that the separated thread (#1) locks and unlocks 
>>> this mutex many times without letting the principal thread locking 
>>> it, for a quite long time (around 100 milliseconds).
>>>
>>> This problem results in jerky effects on the user interface.
>>>
>>> I think that this problem should also happen for other Tracker 
>>> classes, since this behaviour is implemented in the main Tracker class.
>>>
>>> To resolve this, I would suggest to insert a call to the sleep method 
>>> in the infinite loop of the separated thread (at least 1 or 2 
>>> milliseconds), in order to let the principal thread lock the buffer 
>>> and update TrackerTools informations.
>>>
>>> Did anyone also meet this problem before ?
>>> Do you think my suggestion could be integrated to the igstk cvs 
>>> repository ?
>>>
>>> Thank you,
>>>
>>> Vincent
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at 
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-users
>>>
>>>
> 
>