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

Subject: Re: [boost] [COUNTERTREE + SUBALLOCATOR ] version 2.0
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-08-29 07:42:05

On Aug 28, 2013, at 5:06 PM, Jeremy Maitin-Shepard <jeremy_at_[hidden]> wrote:

> Francisco José Tapia <fjtapia <at> gmail.com> writes:
> 
>> 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.

At the very least, it is wise to see whether the code should be refactored, to simplify Multi-Index integration, before too much more work is done that might be harder to refactor later.

>> 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.  

Absolutely. The special operations provided don't cover every use case and never can without creating an enormous, hard to grok library. Leave the creation of ad hoc, thread-safe, meta-operations to the users.

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

+1

> 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.

+1

___
Rob

(Sent from my portable computation engine)