Fix class BoundedAttributes to have RLock rather than Lock

[hyoinandout]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

The change fixes the class BoundedAttributes to have RLock rather than Lock. Fixes #3858 (issue). Motivation of this PR is that a deadlock symptom was observed while using the Opentelemetry _logs API. No additional dependencies are required for this change.

Type of change

Please delete options that are not relevant.

• [x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

It seems that a dedicated test case is required.

Does This PR Require a Contrib Repo Change?

Answer the following question based on these examples of changes that would require a Contrib Repo Change:

• The OTel specification has changed which prompted this PR to update the method interfaces of opentelemetry-api/ or opentelemetry-sdk/

• The method interfaces of test/util have changed

• Scripts in scripts/ that were copied over to the Contrib repo have changed

• Configuration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in

  • pyproject.toml
  • isort.cfg
  • .flake8

• When a new .github/CODEOWNER is added

• Major changes to project information, such as in:

  • README.md
  • CONTRIBUTING.md

• [ ] Yes. - Link to PR:

• [x] No.

Checklist:

• [x] Followed the style guidelines of this project
• [ ] Changelogs have been updated
• [ ] Unit tests have been added
• [ ] Documentation has been updated

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: hyoinandout (c82af5bd0e434bb805acf1b084bcb9177f8350e4, 8cda435db6f4da38b6dcb202db71adfb133c97bb, da467be673866d4b774962f958ee504589d178e7, 2635f07ff7003d57bc46d74813e0cd99e17ffd3c, e9e1a3e0e497abaf80ff033324d57754ae589237, 4e3cfb4eeb15eaf467ac4ff81aa64194166e976a, d7ec07c02563be710806d6ea02414ac3b6abbf98, 24f8e6ce39fbef585a215bcf27dcc78014ae0af3, 7822e09a03685322036d1ff86fbf281514eced40)
• :white_check_mark: login: ocelotl / name: Diego Hurtado (13cc549d30f0f0eae7eb03efa39c73a873a96249)

[xrmx]

@hyoinandout please rebase and add a changelog to have green tests

[hyoinandout]

@xrmx Thank you for giving me a heads up. I rebased my branch on top of main branch and added a changelog for this PR.

[xrmx]

@hyoinandout The test you added is failling on a specific combination

[hyoinandout]

@xrmx I will have my eyes on it, but since I am not an expert of this build environment, I'm not sure that I will find the reason. Could you share your opinion why the test is failing in such specific environment?

[emdneto]

From the pipelines, the test is failing on the build Windows 2019 check. From the logs, it seems that thread 2 reads the value from bdict before Thread 1 modifies it, and then Thread 2 modifies it before Thread 1 writes its doubled value. For this reason, the final value might not be the expected 4x as you want. It seems the behavior in Windows is unstable

[ocelotl]

@lzchen I think we should probably skip this test case for the failing Windows environment, what do you think?

[xrmx]

The test is racy though, the lock is in __setitem__ and does not cover the reading of the actual value in __getitem__. So maybe just set a fixed value and assert that all elements have been set. We are testing that there was a deadlock and now it's gone so it should be fine.

[hyoinandout]

@xrmx Now I fully get the point. I really appreciate your explanations for it and just have pushed a commit to test it like it is.

[hyoinandout]

See the comment for the deadlock which motivated this PR.