thread_safe_bus.state (getter) should not use locks

未关闭

#1,891 创建于 2024年11月7日 0 条评论 0 个 reaction 已指派 0 人在 GitHub 查看

还没有人认领这个 Issue。

评估

难度: 4/5
预计耗时: 3-5 天
新手友好度: 35/100

Issue 类型: 缺陷
描述清晰度: 基本清楚
活跃度: 停滞
技术栈: python
领域: networking

调研方向

首先阅读 thread_safe_bus.py 以及 issue 中展示的 state 属性，然后跟踪 thread-safe bus 如何使用 send 和 receive 锁。确定 state 读取是否需要独立于这些锁的同步；当 state 检查不再等待 listener，同时在并发 send 和 receive 操作期间保持安全时，即视为完成。

由索引模型根据 Issue 内容生成。

描述

enhancement

Problem description

I have a small application that listens on one thread, and may send on another (using asyncio). Before sending, I used to check the hardware state by evaluating the .state property. I use the thread safe bus.
However, this leads to long wait phases, depending on incoming messages.

It turns out that getting the .state property locks both send and receive locks, whereas lock_recv is probably occupied by the listener most of the time, which causes the delays.
in thread_safe_bus.py:

    @property
    def state(self):
        with self._lock_send, self._lock_recv:
            return self.__wrapped__.state

Proposed change

I am not very familiar with thread-safe communication in Python, but derived from my C++ knowledge, the value of the .state property is only an enum value and should be atomic anyway, especially when reading.
So from my point of view, I would either just return the value without locks. Or - if any locking is needed for some reason - use a separate state-access-lock that is independent from lock_send and lock_recv.

Workaround

I guess checking the bus state before each send() call is not the correct way to do. I switched to a mere send() and catch a CanError exception afterwards, which works fine without delay.

主要语言: Python
星标: 1.6k
派生: 697
PR 合并指标: 30 天内没有已合并 PR