Monday, April 29, 2019

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 29 01:07PM -0700

On 4/29/2019 3:53 AM, Paavo Helde wrote:
> and modify only the shared_ptr and weak_ptr objects themselves and not
> objects they refer to. Changes in use_count() do not reflect
> modifications that can introduce data races." ([util.smartptr.shared]).
 
The problem is that the loading of the pointer and refcount increment
need to be a single atomic op in the internals of the ref count impl.
However, if the global_ptr was guaranteed to always point to the exact
same object, and was created and fully initialized _before_ any other
thread can access it, it might be okay. Humm... But, this is basically a
singleton?
 
 
> and one has to e.g. wrap it inside a std::atomic or apply some external
> locking (std::shared_ptr::atomic_load() will be deprecated in C++20 in
> favor of std::atomic wrapping).
 
I am just not sure about the "special case" where the global_ptr is
completely setup before any threads can access it, and is guaranteed to
never change. But, why not use a singleton here?
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 29 08:32PM

> same object, and was created and fully initialized _before_ any other
> thread can access it, it might be okay. Humm... But, this is basically a
> singleton?
 
No. Shared ptr is always initialized in single thread.
Having global shared ptr beats the purpose of shared ptr. In that case
raw pointer would suffice.
"Chris M. Thomasson " <ahh_f_it@crap.nothing>: Apr 29 02:25PM -0700

On 4/29/2019 1:32 PM, Melzzzzz wrote:
 
> No. Shared ptr is always initialized in single thread.
> Having global shared ptr beats the purpose of shared ptr. In that case
> raw pointer would suffice.
 
Humm... Raw pointer doesn't suffice because it would not be reference
counted? Take a deep look at differential reference counting:
 
http://www.1024cores.net/home/lock-free-algorithms/object-life-time-management/differential-reference-counting
 
Dmitry, Joe and I have worked on this in the past over on
comp.programming.threads. Have you ever seen atomic_ptr by Joe Seigh?
Here is the patent:
 
https://patents.google.com/patent/US5295262
 
The idea is to have an atomic reference counted pointer that fully works
in the following scenario:
____________________________
static atomic_ptr<foo> g_foo = new foo();
 
// thread readers
for (;;)
{
local_ptr<foo> lfoo = g_foo;
 
// can test lfoo for a null object if needed
 
lfoo->read();
}
 
// thread writers
for (;;)
{
local_ptr<foo> next_foo = new foo();
g_foo = next_foo;
}
____________________________
 
This is strong thread safety and does not work with std::shared_ptr
as-is without some external sync.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 30 12:41AM +0300

On 29.04.2019 23:07, Chris M. Thomasson wrote:
> same object, and was created and fully initialized _before_ any other
> thread can access it, it might be okay. Humm... But, this is basically a
> singleton?
 
Yes, it might be a singleton. Singletons are needed sometimes. The
singleton itself would not need refcounting, but it might be needed to
pass it to interfaces which normally expect smartpointers to other,
shorter-lived objects. The singleton might play a role of a "fallback"
or "default" object in this scenario.
 
Another scenario is that the smartpointer is a non-changing member of
another shared object. The calling code copies the smartpointer member
for later use, no locking needed. Now the containing shared object can
be released safely. No singletons around.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 29 04:19PM -0700

On 4/29/2019 2:41 PM, Paavo Helde wrote:
> another shared object. The calling code copies the smartpointer member
> for later use, no locking needed. Now the containing shared object can
> be released safely. No singletons around.
 
Afaict, shared_ptr does not allow a thread to take a reference to an
object if it does not already own one. It can if external sync is used.
Not sure about the special case where shared_ptr will never change and
always points to the exact same address, forever.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 29 04:19PM -0700

On 4/28/2019 11:41 PM, Juha Nieminen wrote:
>> any other thread then you have race condition. So you have
>> to put locks around it.
 
> "Write it"? Write what, exactly?
 
Writing to global_ptr would be:
 
global_ptr = new foo();
 
Reading from it would be:
 
local_ptr = global_ptr.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 29 07:26PM +0200

>> Better use a unordered_map to a scalar value on which you do a switch.
 
> Why do you think unordered_map is better?
 
It's a short solution with a moderate performance.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 10:51PM +0300

On 29.04.2019 22:19, Bart wrote:
> took zero seconds. It takes extra effort to make allowances for
> optimising compilers and makes sure you are comparing how long it takes
> to do a task, rather than how long it takes NOT to do it.
 
Right, it is definitely easier to look for the lost wallet under street
lamps only ;-)
 
> 3.5:1 for gcc-O3, compared with 3.2:1 using the original compiler, and
> 2.5:1 using gcc-O0.
 
> The perfect hash version is still slower.
 
Thanks for the numbers, these are now informative!
Christian Gollwitzer <auriocus@gmx.de>: Apr 29 11:24PM +0200

Am 29.04.19 um 19:44 schrieb Bart:
 
> This method also requires a strcmp, which I thought odd given that this
> is supposed to a perfect hash; just length compare will do as the only
> clashes are with names that are different lengths.
 
The strcmp is necessary to check that the input was indeed part of the
keywords, so that when you input "xxx" and it hashes to one of the
menaingful slots, it doesn't get interpreted as "Wednesday"
accidentally. The hash is only perfect over the set of input values. As
to the speed, I don't know, either it is only advantageous for larger
numbers of keywords or lists of words that are not separated as easily,
or perfect hashes are not as good in practice as they are in theory.
 
Maybe also looking up only always the same string is not a good
benchmark, because of the jump prediction of the processor.
 
Christian
 
Bart <bc@freeuk.com>: Apr 29 11:01PM +0100

On 29/04/2019 22:24, Christian Gollwitzer wrote:
> to the speed, I don't know, either it is only advantageous for larger
> numbers of keywords or lists of words that are not separated as easily,
> or perfect hashes are not as good in practice as they are in theory.
 
I can make it nearly double its speed by tightening it up: just doing
strcmp on the full string, rather then checking the first characters
then strcmp on the rest. And by predetermining the search string length.
 
(Note: that search does not return the 0..6 index of the original switch
version, to denote Monday to Sunday, only the original string. So here
I'm only testing for inclusion of an arbitrary string in the set, not
which one.)
 
However, a version simply doing a linear search (and which does return
the index) isn't that much worse than my tweaked perfect hash version
(it had been faster).
 
I think this data set is just too small to show the advantages of
different approaches.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)