The fasteners lib in version 0.15.0 removed the
threading.current_thread workaround for eventlet[1] because eventlet
seemed to fixed the current_thread issues tracked in [2]. However the
fix for [2] only fixed half of the problem. The threading.current_thread
call works if it is called from thread created by eventlet.spawn.
However if the thread is created with eventlet.spawn_n then
threading.current_thread is still broken and returns the ID of the
python native thread.
The fasteners' ReaderWriterLock depends heavily on
threading.current_thread to decide which thread holds a lock and to
allow re-entry of that thread. This leads to the situation that
multiple threads created from spawn_n could take the same
ReaderWriterLock at the same time.
The fair internal lock in oslo.concurrency uses ReaderWriterLock and
as a result such lock is broken for threads created with spawn_n.
Note that this issue was raised with eventlet in [3] when the nova team
detected it via a direct usage of ReaderWriterLock in the nova test
code. As [3] did not lead to a solution in eventlet nova implemented a
nova local fix for the test code in [4].
However now we detected that oslo.concurrency is affected by this issue
as well.
This patch adds tests to show the scope of the problem.
Note that the coverage tox target is changed to explicitly enable native
threading otherwise it runs eventlet specific tests in a native
environment.
Also note that [5] was opened to reintroduce the workaround[1] in fasteners.
Reviewed: https:/ /review. opendev. org/c/openstack /oslo.concurren cy/+/855713 /opendev. org/openstack/ oslo.concurrenc y/commit/ 796203c94846d44 237d869e3b20a6c d8a3602e36
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 796203c94846d44 237d869e3b20a6c d8a3602e36
Author: Balazs Gibizer <email address hidden>
Date: Sat Sep 3 13:16:56 2022 +0200
Prove that spawn_n with fair lock is broken
The fasteners lib in version 0.15.0 removed the current_ thread workaround for eventlet[1] because eventlet current_ thread current_ thread is still broken and returns the ID of the
threading.
seemed to fixed the current_thread issues tracked in [2]. However the
fix for [2] only fixed half of the problem. The threading.
call works if it is called from thread created by eventlet.spawn.
However if the thread is created with eventlet.spawn_n then
threading.
python native thread.
The fasteners' ReaderWriterLock depends heavily on current_ thread to decide which thread holds a lock and to rLock at the same time.
threading.
allow re-entry of that thread. This leads to the situation that
multiple threads created from spawn_n could take the same
ReaderWrite
The fair internal lock in oslo.concurrency uses ReaderWriterLock and
as a result such lock is broken for threads created with spawn_n.
Note that this issue was raised with eventlet in [3] when the nova team
detected it via a direct usage of ReaderWriterLock in the nova test
code. As [3] did not lead to a solution in eventlet nova implemented a
nova local fix for the test code in [4].
However now we detected that oslo.concurrency is affected by this issue
as well.
This patch adds tests to show the scope of the problem.
Note that the coverage tox target is changed to explicitly enable native
threading otherwise it runs eventlet specific tests in a native
environment.
Also note that [5] was opened to reintroduce the workaround[1] in fasteners.
[1] https:/ /github. com/harlowja/ fasteners/ commit/ 467ed75ee1e9465 ebff8b5edf45277 0befb93913 /github. com/eventlet/ eventlet/ issues/ 172 /github. com/eventlet/ eventlet/ issues/ 731 /review. opendev. org/c/openstack /nova/+ /813114 /github. com/harlowja/ fasteners/ issues/ 96
[2] https:/
[3] https:/
[4] https:/
[5] https:/
Related-Bug: #1988311 5b46ebd2aac82ea 89e33f885f0
Change-Id: Ibc193c855b49b9