Re: [boost] [COUNTERTREE + SUBALLOCATOR ] version 2.0

Subject: Re: [boost] [COUNTERTREE + SUBALLOCATOR ] version 2.0
From: Francisco José Tapia (fjtapia_at_[hidden])
Date: 2013-08-29 13:19:41

Obviously, I can't pretend cover all possible cases with the interface
functions, but a great percent of them yes.

Mi idea is to try to resolve in a easy way, the majority of the possible
cases, because many programmers don't know in deep the lock functions and
need to resolve simple problems with concurrent data structures.

 The idea of the function as parameter is for to do something. This can be
so complex as you need. Inside a function you can call other function of
the same data structure, because the internal mutex used for to lock is
recursive.

If this is not sufficient, you can use the lock data of the data structure
directly because is public. In all the data structures is the variable BD.

The description and functions of the locks is in the file barrier.hpp in
countertree folder of the code.

All the data structures have typedef in order to simplify the names

typedef typename config_barrier<cnc>::barrier_data barrier_data ;

typedef typename config_barrier<cnc>::barrier_read barrier_read ;

typedef typename config_barrier<cnc>::barrier_modify barrier_modify ;

 you have a

 cntree::set<int> S1;

 your_function( ......)

{

    cntree::set<int>::barrier_modify BM ( S1.BD);

        .

    BM.wait_no_readers();

        .

};

 but if your lock concern several data structures you must create your own
lock data structures and manage them.

About the overhead of the std::functions I didn't know, but I suspect
because I didn't see it in the functions of the standard library. I will
change soon.

Thanks

Francisco Tapia