Locked resources are easily stolen by other VISA implementation

[Ben3094]

When I apply an exclusive lock to a session, the session can be stolen by another session. I tested this using pyvisa with pyvisa-py on one computer and pyvisa with IVI VISA installed on the other computer.

To Reproduce

Steps to reproduce the behavior:

1. Create a pyvisa resource with exclusive lock on the PC with only pyvisa-py.
2. Create the same pyvisa resource with exclusive lock on another PC with IVI VISA implementation
3. The second PC is now connected to the ressource and can write command while it should not
4. Try to write command from the pyvisa-py PC and it raise an error...

[MatthieuDartiailh]

What kind of session are you using ?

[Ben3094]

Both are sessions with exclusive lock

[MatthieuDartiailh]

I meant are you using GPIB, TCPIP, USB ?

[Ben3094]

Sorry, TCPIP.

[MatthieuDartiailh]

Which protocol ? hislip or VXI11 (the default is VXI11 for TCPIP)

[Ben3094]

I think VXI11 as second to last address word is "inst0".

[MatthieuDartiailh]

It is VXI11. I will need to check the code, I am not sure how locking is handled.

[MatthieuDartiailh]

Checking the VXI11 specs, there is not special option to locking beyond whether or not to block when attempting to acquire the lock. So I do not see what we may be doing wrong. Could you attempt to capture the network traffic when locking using pyvisa-py and using NI ?

[Ben3094]

I use pyvisa-py on one PC and keysight IO installation on the other.
It will take time but I will do it for sure. 😉

[MatthieuDartiailh]

Thanks !!!

[Ben3094]

It appears that the pyvisa-py PC does not call DEVICE_LOCK as the Keysight IO equipped PC... Both are running the same test code and using the same library (that use pyvisa)...
The library is different that the one you see as I add "exclusive_lock" on both PC.

self.__resource__ = DEFAULT_RESOURCE_MANAGER.open_resource(self.Address, timeout=self.__timeout__, access_mode=AccessModes.exclusive_lock)

[Ben3094]

It seems that highlevel.py open method does not use access_mode argument.
https://github.com/pyvisa/pyvisa-py/blob/main/pyvisa_py/highlevel.py#L119
Does it mean that it is not supported for the moment ?
If yes, I will try to help to resolve this. 😉

[MatthieuDartiailh]

You are welcome to make a PR. For the specific case at hand, I suggest you start with only supporting exclusive locking. Reading the specs I think shared lock cannot work between VISA libraries. However supporting properly nested locking seems worth it. Let me know if you need any guidance.

[arr-ee]

Note that there is a (partially implemented, lock type is not being respected at the moment) implementation of Session#lock in TCPIPInstrVxi11 and underlying RPC client — might be worth checking if that does what you're looking for, and build from there.

[Ben3094]

Do you recommand me a document to build the implementation from it ?

[MatthieuDartiailh]

You can have a look at the VISA specification here: https://www.ivifoundation.org/downloads/Architecture%20Specifications/IVIspecstopost10-22-2018/vpp43_2018-10-19.pdf
As I said I suggest focusing on exclusive locking with proper support for nested locking (which may or may not require to keep track of the level of nesting on pyvisa-py side since the VXI-11 specs does not mention multiple locking).