J
jacob navia
I am introducing a new container into the container library: Treemap.
This one features a scapegoat tree, and NEEDS a comparison function to
be able to build the tree.
Normally, comparison functions takes two arguments, for instance the
argument to the qsort() function.
Within the context of the container library, I propose to use
comparison functions that can take a third argument, where you
can pass a context to the function without having to use global
variables.
Now, maintaining this third argument has been quite a pain, since
it implies (ofcourse) that in all my calls to qsort() I would
need a special qsort, augmented with extra arguments.
Now in my tree function, I have:
int Add(TreeMap *tree, void *data, void *ExtraArgs);
where "ExtraArgs" are the extra arguments to pass to the
comparison function.
My problem is that in all sequential containers I have
int Add(Container *someContainer, void *data);
and it would be real NICE if I could keep that function with
the same syntax.
To solve this problem, I added a void * in the TreeMap
structure to contain the extra arguments for the comparison function
in case you need them. So, you would do:
TreeMap *tree;
void *Context;
// initialize tree and Context
SetComparisonContext(tree,Context);
Add(tree,data);
SetComparisonContext(tree,NULL);
So, you would pass the extra arguments in the tree itself.
Problem is, I am not sure of the implications of this stuff in
a multi-threaded environment. I would have to lock the tree to
modifications between the call to the first SetComparisonContext
and the second. Since the tree must be locked anyway for the
add this doesn't look very catastrophic anyway, but now the
"Add" function must NOT try to lock again the tree since it is
already locked. This means that the locking primitives must
notice if the tree is locked by the SAME thread and ignore the
lock.
All this quickly goes beyond the feeble capacities of my
small brain
Hence this message and a question:
Better modify the syntax of the functions than getting into the
multi-threading hair splitting?
What do you think?
Thanks in advance for any help.
jacob
This one features a scapegoat tree, and NEEDS a comparison function to
be able to build the tree.
Normally, comparison functions takes two arguments, for instance the
argument to the qsort() function.
Within the context of the container library, I propose to use
comparison functions that can take a third argument, where you
can pass a context to the function without having to use global
variables.
Now, maintaining this third argument has been quite a pain, since
it implies (ofcourse) that in all my calls to qsort() I would
need a special qsort, augmented with extra arguments.
Now in my tree function, I have:
int Add(TreeMap *tree, void *data, void *ExtraArgs);
where "ExtraArgs" are the extra arguments to pass to the
comparison function.
My problem is that in all sequential containers I have
int Add(Container *someContainer, void *data);
and it would be real NICE if I could keep that function with
the same syntax.
To solve this problem, I added a void * in the TreeMap
structure to contain the extra arguments for the comparison function
in case you need them. So, you would do:
TreeMap *tree;
void *Context;
// initialize tree and Context
SetComparisonContext(tree,Context);
Add(tree,data);
SetComparisonContext(tree,NULL);
So, you would pass the extra arguments in the tree itself.
Problem is, I am not sure of the implications of this stuff in
a multi-threaded environment. I would have to lock the tree to
modifications between the call to the first SetComparisonContext
and the second. Since the tree must be locked anyway for the
add this doesn't look very catastrophic anyway, but now the
"Add" function must NOT try to lock again the tree since it is
already locked. This means that the locking primitives must
notice if the tree is locked by the SAME thread and ignore the
lock.
All this quickly goes beyond the feeble capacities of my
small brain
Hence this message and a question:
Better modify the syntax of the functions than getting into the
multi-threading hair splitting?
What do you think?
Thanks in advance for any help.
jacob