Is andor camera code thread-safe?

[jkotan]

Hi,

I've just looked at the andor code because of random errors of its tango server in our facility.
Therefore I would like to ask if someone test the code with respect of thread-safety, i.e.

In AnodorCamera there is an implementation of thread AcqThread (in threadFunction()) which shares non-atomics (std::atomic) variables with the main thread, e.g.:

• m_cam.m_wait_flag read in AcqThread (without lock) but it can be changed in startAcq or 'stopAcq' (with lock) in the main thread
• m_cam.m_nb_frames read in AcqThread (without lock) but it can be changed in setNbFrames (without lock) in the main thread
• m_cam.m_image_number changed/read in AcqThread (without lock) but it can be read in getNbHwAcquiredFrames in the main thread (without lock)

Moreover access to m_cam.m_buffer_ctrl_obj (without locks) in both threads looks suspicious
(e.g. newFrameReady(...) and getFrameBufferPtr(...)) .

Finally, WaitForAcquisition() and GetNumberNewImages(...) and GetImages16(...) are implemented in a thread-safe way (Otherwise one has to use mutex for all andor native commands).

Best regards,
Jan

[laurent-claustre]

Hi, we run andor with Lima tango server on beamlines without trouble. Ok the AndorCamera.cpp is maybe not thread-safe enough. But could you tell me more about your tango server random errors?
Some back traces?

[laurent-claustre]

Are you using Tango atkpanel tool as client?

[jkotan]

Our usersIt often reports that during acqusiton when they access camera with jive the tango server hangs or crashes randomly.

[laurent-claustre]

humm, I cannot help you without more details.

[jkotan]

I think enough helpful would be to fix the thread-safety bugs by inserting additional locks and/or atomic variables

[laurent-claustre]

ok, please make a pull-request, we like contribution.