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

why is it thread-unsafe? #14

Open
kenxausten opened this issue Jun 15, 2020 · 4 comments
Open

why is it thread-unsafe? #14

kenxausten opened this issue Jun 15, 2020 · 4 comments

Comments

@kenxausten
Copy link

From the code, I can't find it is thread-unsafe, why is it thead-unsafe?

@zeromus
Copy link

zeromus commented Jun 15, 2020

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.

@lfnoise
Copy link

lfnoise commented Jun 17, 2020

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.

@tigerccx
Copy link

tigerccx commented Jul 8, 2022

Has anyone benchmarked its performance after made thread safe? If so, how it is compared to 'malloc' and 'free'?

@lfnoise
Copy link

lfnoise commented Jul 8, 2022

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.

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

No branches or pull requests

4 participants