ZMQError: error: lock not held

8 views
Skip to first unread message

David La Mantia

unread,
Feb 6, 2026, 4:56:25 PM (14 days ago) Feb 6
to the labscript suite
Hello all,

TYIA for any advice.

I have a Pendulum frequency counter as a user_device that's working quite well, except when I want it to take data for longer than about 10 s.

There, in transition_to_biffered the last thing I have it do is print 'Pendulum is done counting'

Then it throws the following error chain (below).  I've tried doing what https://groups.google.com/g/labscriptsuite/c/QJYqdTslVPM/m/iuRModpEBAAJ
did, but to no avail.

Ideas?

Taking measurement: 100%|##########| 100/100 [01:40<00:00, 1.01s/s]

 

Pendulum is done counting.

Pendulum is done counting.

2026-02-06 14:07:46,367 ERROR BLACS.pendulum_main_worker.worker: Exception in job:

Traceback (most recent call last):

File "C:\Users\Lab\anaconda3\envs\labscript\lib\site-packages\blacs\tab_base_classes.py", line 898, in _transition_to_buffered

return self.transition_to_buffered(

File "C:\Users\Lab\labscript-suite\userlib\user_devices\Pendulum\blacs_workers.py", line 99, in transition_to_buffered

print('Pendulum is done counting.')

File "C:\Users\Lab\anaconda3\envs\labscript\lib\site-packages\labscript_utils\h5_lock.py", line 85, in __exit__

self.close()

File "C:\Users\Lab\anaconda3\envs\labscript\lib\site-packages\labscript_utils\h5_lock.py", line 64, in close

self.zlock.release()

File "C:\Users\Lab\anaconda3\envs\labscript\lib\site-packages\zprocess\zlock\__init__.py", line 246, in release

self.client.release(self.key, self._client_id)

File "C:\Users\Lab\anaconda3\envs\labscript\lib\site-packages\zprocess\zlock\__init__.py", line 195, in release

raise zmq.ZMQError(response)

zmq.error.ZMQError: error: lock not held


Chris Billington

unread,
Feb 6, 2026, 5:08:58 PM (14 days ago) Feb 6
to labscri...@googlegroups.com
Hi David,

To prevent multiple programs trying to read/write HDF5 files whilst one is writing to it, access to the files is protected by a lock. But the lock has a timeout, I believe it's something like 45 seconds by default, and if a program doesn't release the lock in that time (by closing the HDF5 file), it is released automatically. The error you're seeing indicates an HDF5 was kept open for longer than that timeout.

This suggests your code keeps the HDF5 file open for a long time during the acquisition. Actually, it looks like the acquisition all happens within transition_to_buffered(), which takes 100 seconds.

You should have transition_to_buffered() open the HDF5 file, read anything it needs, and then close it. If some data-reading code needs to continue running during the shot, transition_to_buffered() should spawn a thread to do this, so the thread can keep running after transition_to_buffered() returns. The thread should store the results temporarily in memory, rather than writing to the HDF5 file. Then in transition_to_manual(), the thread should be stopped, the HDF5 opened again, and the acquired data written to it.

That way the file is only ever open for short times, which is important so other devices' blacs workers can access it if they need to, and will avoid holding the lock for longer than the timeout.

Hope that's helpful,

Chris



--
You received this message because you are subscribed to the Google Groups "the labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/labscriptsuite/f9d4c332-5743-4434-976e-d79583e77478n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages