Having coded a test implementation for the queue, I’m of the view that this is a bad idea. The idea is supporting a freelist is good, but providing it as a special case of a user definable malloc and free is not. I have no known user need for a user defined malloc/free and there is a lot of user facing complexity in using those functions to use a freelist for allocation.
Instead, I’m going to have each data structure internally support the use of a freelist. The user will have a config option where he can indicate the internal freelist should be used.
In other news, I’ve more or less accepted the user has to register a thread once and pass the thread SMR state into function calls. It blows, but you can’t have a fast path if you’re doing a hash lookup every time.
This means I have to deal with deferred data structure state deletion. Really, this is just another usual aspect of SMR…
I have also decided (as mentioned before) to return the DCAS data structures. When instantiating a data structure, the user will indicate the type, an enum argument. (In fact, I might even use that argument as a way for the user to indicate if malloc or a freelist should be used).
Comments are closed.