Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support rwlock's in pthread (IDFGH-5690) #7411

Closed
MabezDev opened this issue Aug 12, 2021 · 2 comments
Closed

Support rwlock's in pthread (IDFGH-5690) #7411

MabezDev opened this issue Aug 12, 2021 · 2 comments
Labels
Resolution: Done Issue is done internally Status: Resolved Issue is done internally Type: Feature Request Feature request for IDF

Comments

@MabezDev
Copy link
Collaborator

MabezDev commented Aug 12, 2021

As part of an ongoing effort to bring Rust support to Espressif chips, one requirement we found is the need for rwlock to fully support the Rust standard library. For our initial implementation was accepted on the basis that rwlock support would come to esp-idf soon ™️ (rust-lang/libc#2310 (comment)).

We are currently getting away with the lack of support with a nasty hack using a mutex. Obviously we want to get rid of this asap.

@MabezDev MabezDev added the Type: Feature Request Feature request for IDF label Aug 12, 2021
@espressif-bot espressif-bot added the Status: Opened Issue is new label Aug 12, 2021
@github-actions github-actions bot changed the title Support rwlock's in pthread Support rwlock's in pthread (IDFGH-5690) Aug 12, 2021
@0xjakob
Copy link
Collaborator

0xjakob commented Aug 25, 2021

@MabezDev Any requirements regarding the implementation? In particular, is writer starvation prevention necessary?

@MabezDev
Copy link
Collaborator Author

From the Rust standard library on the RWLock's:

The priority policy of the lock is dependent on the underlying operating system’s implementation, and this type does not guarantee that any particular policy will be used. In particular, a writer which is waiting to acquire the lock in write might or might not block concurrent calls to read.

Therefore I don't think we need writer starvation prevention initially, and we are open to change it later if we wish too. I think for now the simplest implementation will do.

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Aug 30, 2021
@espressif-bot espressif-bot added Status: Reviewing Issue is being reviewed and removed Status: In Progress Work is in progress labels Oct 18, 2021
@espressif-bot espressif-bot added Resolution: Done Issue is done internally Status: Resolved Issue is done internally and removed Status: Reviewing Issue is being reviewed labels Nov 9, 2021
espressif-bot pushed a commit that referenced this issue Nov 10, 2021
* Added implementation based on cond. variables
* Added unit tests

Closes #7411
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Resolved Issue is done internally Type: Feature Request Feature request for IDF
Projects
None yet
Development

No branches or pull requests

3 participants