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