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

Subject: Re: [boost] [COUNTERTREE + SUBALLOCATOR ] version 2.0
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2013-08-28 17:06:08

Francisco José Tapia <fjtapia <at> gmail.com> writes:

> 
> Hi Jeremy
> 
> Thanks by your interest in the library
> 
> About the interface with Multi Index, I think it's a good idea, but I think
> first we must build a robust library with all the functionality, and to be
> checked by the Boost users, and after export ideas and code to others
> libraries. I insist in the checking of the users for don't export bugs and
> problems.

It is reasonable to not want to deal with the added complexity of Multi
Index initially, though if you decide to add it later it seems you would
either have to maintain two copies of the code, or make the non Multi Index
version just a wrapper over Multi Index.

> About the synchronization, my idea is to do a lock-free data structure from
> the user view-point. The locks are automatic, and don't be managed by the
> users. The users don' need lock, only must take care about what they want
> to do. But for a safe code they must use the new functions.

The basic issue is that if you want the user to not have to worry about
locking, then you must perfectly anticipate precisely which operations the
user needs to appear atomic.  You have added various predicate-enabled
operations, but there is no guarantee that one of those happens to fit what
the user needs.  For example:

 - the user may want to perform some combined insert/erase operation and
have it appear atomic to other threads;
 - any use of iterator traversal will require manual locking by the user;
 - the user may want to atomically combine modifications to the data
structure with modifications to the values in the data structure;
 - the user may need to atomically modify multiple data structures.

>From my perspective, forcing users writing multithreaded code to think
carefully about synchronization/locking is a good thing.  It is true that

x.insert_if(..., [&]{
  // check some stuff here
});

is shorter than

{
  std::lock_guard<std::mutex> guard(my_mutex);
  if  (/* check some stuff here */) {
    x.insert(...);
  }
}

but it isn't that much shorter, and the second version is more
straightforward and is much more general.

Perhaps others agree with you though that having a convenience interface for
users, even if it is limited in capability, is still useful.

One small comment regarding your interface of predicate-enabled functions is
to pass functors using a template type, like the standard library and other
boost libraries generally do, rather than using std::function, as
std::function introduces extra overhead.