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

Implement new interprocess lock #7

Merged
merged 10 commits into from
Dec 16, 2019
Merged

Implement new interprocess lock #7

merged 10 commits into from
Dec 16, 2019

Conversation

Squadrick
Copy link
Owner

Complete rewrite of the reader writer lock using pthread directly, and check for EOWNERDEAD to prevent resource starvation

Complete rewrite of the reader writer lock using pthread
directly, and check for `EOWNERDEAD` to prevent resource
starvation
OSX supports only SUSv2 for pthread which doesn't support
the functionality used by the new lock
@Squadrick Squadrick added the wip label Dec 3, 2019
@Squadrick
Copy link
Owner Author

IPC_Lock::consistency_handler()'s handling of the ENOTRECOVERABLE error code from pthread_mutex_lock() does not look right. The process that gets this error code does not acquire the lock, yet unlock is called later. Also destroying and reinitializing an object without holding any locks seems really racey. I don't know if there is a sensible way of recovering from this error.

@Squadrick
Copy link
Owner Author

There are more problems when a process dies that is holding a lock. counter never gets updated. Also, a writer could acquire the g lock even if there are many readers if the one reader that is actually holding the lock dies, then the writer would think it would have unique ownership when there are actually many readers out there. Also is a pthread_mutex allowed to be unlocked by a different thread/process than what locked it? From a quick glance of the docs it seems like not, but I didn't look hard.

@Squadrick Squadrick merged commit 3e89110 into master Dec 16, 2019
@Squadrick Squadrick deleted the new-lock branch December 22, 2019 22:05
@Squadrick Squadrick removed the wip label Jun 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant