220 15358 <7635907.qZsrLfD8EO@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: get count of std::weak_ptr objects tracking a shared resource Date: Mon, 29 Dec 2014 11:09:25 -0200 Lines: 69 Approved: news@gmane.org Message-ID: <7635907.qZsrLfD8EO@tjmaciei-mobl4> References: <1855770.LoiCOOISBB@tjmaciei-mobl4> <3921387d-3a99-451b-a599-7899ff4c650f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1419858579 5939 80.91.229.3 (29 Dec 2014 13:09:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Dec 2014 13:09:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBDFFQWSQKGQEPNLEKNY@isocpp.org Mon Dec 29 14:09:34 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y5a4j-00089V-Qc for gclcip-std-proposals@m.gmane.org; Mon, 29 Dec 2014 14:09:33 +0100 Original-Received: by mail-wi0-f198.google.com with SMTP id r20sf8108627wiv.9 for ; Mon, 29 Dec 2014 05:09:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=pSbdjfy3xSltShFfZp+QoxT0eMhfN5bE4ci1Xz/McZo=; b=X0cf2ffPwAUFBEks2h0Lhi5LacIrW/B3iXww3w++JBDvwObAm818mOflckacX5idr5 py6Z3ynJZufTuXmyTNgUqmz/7ZIJd8A+aYsAx+2NPEKQsP4tX//38M7S0jKgISmgOnD3 gufoRXDIdHFt71+EaKU0v8EhH1n9foJnPMMK69YuroLk8wyOv0DkGIC1xyS0E3pv9tB3 r79b8iMR3DfDniUmmzjSCzBkNhRzJdKeWCEbTz2x+wpJ00NMKiyqPmYeH47dYWH0sUE5 /Wj6Mk+/O6zN2CNfRqoc3UvrZ8aNDC9+Q6AhJnqC03uZwfcaz09oHN/5j4MD6RMnUang /Obw== X-Gm-Message-State: ALoCoQnPmVclMC7sK4Ibz5kWkl37nsAyVW5vQHKclEElADieiF7dm9cvCblIqUUethBSW+AigpEg X-Received: by 10.194.95.74 with SMTP id di10mr6592405wjb.0.1419858573119; Mon, 29 Dec 2014 05:09:33 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.83.72 with SMTP id o8ls1697715wiy.13.canary; Mon, 29 Dec 2014 05:09:31 -0800 (PST) X-Received: by 10.180.19.193 with SMTP id h1mr95677365wie.10.1419858571803; Mon, 29 Dec 2014 05:09:31 -0800 (PST) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id lj11si58897145wic.21.2014.12.29.05.09.31 for ; Mon, 29 Dec 2014 05:09:31 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (unknown [189.0.120.56]) by gondolin.macieira.info (Postfix) with ESMTPSA id F1BA211BA19 for ; Mon, 29 Dec 2014 05:09:29 -0800 (PST) User-Agent: KMail/4.14.3 (Linux/3.11.10-21-desktop; KDE/4.14.3; x86_64; ; ) In-Reply-To: <3921387d-3a99-451b-a599-7899ff4c650f@isocpp.org> X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mail=thiago@macieira.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15358 Archived-At: On Monday 29 December 2014 02:18:37 Ramkumar Revanur wrote: > When the user wants to access the cached object, he fetches the cache > object wrapped in a weak_ptr. He can lock this object within a scope to get > hold of the shared_ptr. Within this scope, he will be guaranteed the > validity of the cache object. The worst the library can do is to release > the copy of shared_ptr it has but the reference count is not 0 as within > the current scope, there is a strong owner that feeds the cache object to > the user. > > Now, there could be another process that could be writing to the cache > source (database / file., etc). The caching library can either update those > cached objects that are updated or decide to dispose them based on strategy > that best suits the user. If the user decided to no longer user the cached > object, he can inform the library that he is no longer using it or can > simply drop the weak_ptr and the library will know that there is no active > tracking pointer to the cached object and drop the object. Hope this > explains the motivation to use weak_ptr and weak_count. I find two problems with that API (this is IMO): First, the cache manager should return a shared_ptr, not a weak_ptr, so the user knows that the object she asked for didn't become invalid in the microseconds between the asking and the converting to shared_ptr. If you have an API that returns an explanation for the cache miss, then the cache hit should be a shared_ptr. If, however, it indicates a cache miss by returning a null pointer anyway, then this problem is minimised. Second, since you can't forbid the upgrade to shared_ptr, the user can store shared_ptr of your cached objects and negate your tracking of memory consumption anyway. Moreover, the user should store weak_ptr when she wants to declare "I don't care if this gets deleted". Your design calls for weak_ptr to be used in the same role as shared_ptr, since it influences whether the object gets deleted or not. It sounds like you want an intermediate solution: a) like shared_ptr, is used to make the decision to delete b) like weak_ptr, cannot *stop* the deletion Still IMO, you're abusing weak_ptr by using it in the way you described. The Standard Library cannot be asked to do your job for you. Instead, you should wrap the object and the pointer in your own class that accesses the internal data where required. Your own class can then update an internal count of active references. It can also update an internal age of how recently the object has been used (the coarse monotonic timer on Linux costs little more than one function call to obtain). Therefore, since I find that a solution there is another solution that is a) superior to the weak_ptr solution, b) doesn't abuse weak_ptr for what it wasn't intended, and c) works even in multithreaded programs[*], I am still discounting your scenario as valid. [*] see Message-ID: <9595545.eDdFo9NLoN@tjmaciei-mobl4> for the conclusion that weak_count would be not atomic in two of three scenarios and total_count would also be not atomic in two of three scenarios. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .