Global Locks Not working properly

[Tiiiger]

Hi @whitphx

Thank you so much for the repo!

I am building an annotation interface and I am using global locks to make sure that concurrent users are not annotating the same data.

Here is a super minimal snippet for this. Basic idea is that concurrent users should get different i displayed on their interface.
However, some simple testing shows that multiple session will see the same i. In my case, I see i = 0 in the first session, i =1 in second, third, fourth session ...

Do you have any idea what's going on here? Any fix you'd recommend?

Thank you so much!

import streamlit as st
from streamlit_server_state import server_state_lock

for i in range(10):
    if server_state_lock[f"{i}"].acquire(blocking=False):
        print(f"Acquired lock for {i}")
        break
    else:
        print(f"Failed to acquire lock for {i}")
        continue

st.write("Count = ", i)
# create a submit button and refresh the page when the button is clicked
if st.button("Submit"):
    server_state_lock[f"{i}"].release()

[whitphx]

Hi, thank you for reporting it with an interesting sample code. Let me take time to investigate it.

[whitphx]

Short answer:
You should not use server_state_lock in that way because it is not designed for such kind of purposes.

Description:
server_state_lock is for manipulating complex objects in a thread-safe way.
An important point here is that different Streamlit sessions can have the same thread identity because the thread identifier may be recycled, and server_state_lock[key] that is an RLock object does not lock in the same thread. In other words, as far as I observed, it does not lock in the threads with the same identity which may have been recycled and used multiple times.
This behavior is not a problem for thread-safety because it still can be an exclusive lock as long as it is used to avoid cross-thread simultaneous accesses to a single object because the same multiple thread identity does not exist at the same time.
In contrast, when you use server_state_lock[key] as a unique lock bound to a Streamlit session that is not a thread and has a longer lifetime than a thread, it leads to a problem.