Tomorrow I am off for a vacation, but I wanted to get this out before.
Unfortunately there is some truth to, “If it was hard to write, it should be hard to understand.” ;) My diploma thesis was definitely much easier. There were numerous times, where I had myself convinced, that it was impossible. I had already given up, but then I just had to try one more idea …
Please read the README.md for a description of the API.
High level overview of operation
mulle-aba has various states of operation.
It all starts with
mulle_aba_init which initializes the system and it all ends with
mulle_aba_done. All threads need to call
mulle_aba_register on start and
mulle_aba_unregister at the end.
Resources are freed with
mulle_aba_free. Periodically, but not too often, each thread should call
mulle_aba_checkin to free up resources.
The interesting lock-free part of
mulle-aba is in state 5, where threads call
mulle_aba_free (black). The blue operations are soft-locking. Here threads have a chance of being locked out by deficient other threads.
Some points of interest
Here are some points to be aware of.
Q: Where is the lock ?
A: The lock is during registration and unregistration of threads. It does NOT affect running registered threads.
Q: Where is the leak ?
A: Some pieces of memory can only be reclaimed after all threads have joined. If you have threads registering and unregistering all the time, you will incur a leak at every unregistration. These leaks will be freed when you call
Q: What is the worst case scenario ?
A: If a registered thread is stuck in
getchar(), while other threads are running and freeing stuff. mulle-aba will be even worse than just leaking, because of overhead.
Q: How is the performance best case ?
A: I suspect pretty much optimal :)
Q: Where has this been tested ?
- i386 + x86_64, i5-2557m + i7 4770k, Mac OS X 10.10
- x86_64, Xeon E5 2660 V3, Ubuntu 15.04
- ARM, iPad mini iOS 9
Continue to mulle-aba: How it works, part 1