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

Threaded internal pthread_cond_t always initialized (expensive), though potentially not used #72

Open
dktapps opened this issue Oct 31, 2021 · 2 comments

Comments

@dktapps
Copy link
Member

dktapps commented Oct 31, 2021

pthread_cond_t facilitates wait()/notify() functionality, which aren't needed in the majority of cases. However, the monitor always allocates them, and this accounts for the large majority of the time spent when creating new Threaded objects.

Ways this could be avoided:

  • (ng only) Split wait/notify stuff into its own class, leaving ThreadedBase even more basic
  • Lazy-init pthread_cond_t (I haven't explored whether this is safe or not).
@dktapps
Copy link
Member Author

dktapps commented Nov 1, 2021

Lazy initialization isn't an option since it's possible for multiple threads to try to use wait() simultaneously without using synchronized(). This would lead to a data race and memory leak.

@dktapps
Copy link
Member Author

dktapps commented Sep 2, 2022

If we decide to go with a separate class for this, ThreadedEvent would make sense, with a similar API to Python's threading.Event.

This would also simplify the majority use-case of wait() and notify() by avoiding the need for boilerplate synchronized blocks, amongst other things - the vast majority of uses of wait/notify involve some kind of boolean condition flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant