Re: QuadEM Update rate limited by lock

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Iain,

lock() should not take 6 ms, it should be a few microseconds at most. Your lock must be waiting for another thread. 

You only need to call lock() for threads that you create, not for functions called from other threads, like writeInt32, etc.  

drvTetrAMM.cpp is a good example. readThread() holds the lock except when it is waiting for input from the device (which is most of the time).

Mark

Sent from my iPhone

On Nov 20, 2024, at 10:58 AM, Iain Marcuson via Tech-talk <tech-talk at aps.anl.gov> wrote:



I am writing EPICS for a QuadEM, based on designs in the distribution.  The data come at 200 Hz, and my benchmarking in EPICS shows that I receive at that rate with very low jitter.  Following the examples of other electrometers, I lock() before computePositions() and callParamCallbacks().  I have observed that the lock() takes about 6 ms, which is too long for the full packet rate.  Is this a normal time for the lock()?  I believe I have eliminated other calls for the lock() in my code, although a calltree shows lock()s in the callbacks.

 

Thank you,

 

Iain.

This message has been scanned for malware by Forcepoint. www.forcepoint.com