-
Notifications
You must be signed in to change notification settings - Fork 180
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
why is it thread-unsafe? #14
Comments
There is no portable way to achieve thread-safety. Add thread safety yourself like you would to any other thread unsafe-thing, it should take about five minutes to make wrappers with locks. |
Besides, but related to the portability issue, there’s no simple way to achieve thread safety and also preserve the real-time behavior of this allocator. |
Has anyone benchmarked its performance after made thread safe? If so, how it is compared to 'malloc' and 'free'? |
My opinion: If you use locks to achieve thread safety, then I'd say just use another allocator. The appeal of this allocator is that it is real time. Add locks and then it no longer is real time, so why prefer it? There are other (non-real-time) allocators have been optimized for multi-threaded performance. |
From the code, I can't find it is thread-unsafe, why is it thead-unsafe?
The text was updated successfully, but these errors were encountered: