Picking up from my last message, I should add that in general, the placement new *expression* is certainly not free of data races: initializing at the same address from two different threads without synchronization primitives is certainly a race condition, in the same way as if invoking two new *expression* that would call constructors that would both modify a global variable for instance.

The clause [new.delete.dataraces] only considers the alloc/dealloc functions, they don't apply to the initializing part of the new/delete expressions.

Julien V.


-------- Original Message --------
From: Jason McKesson via Std-Discussion <std-discussion_at_[hidden]>
Sent: December 20, 2022 12:40:36 a.m. EST
To: std-discussion_at_[hidden]
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: [std-discussion] Unsynchronized placement-new

[new.delete.dataraces] states that calling "the library versions of
operator new" is not a data race. It then goes on to talk about memory
allocation and deallocation.

But placement-new doesn't do allocation. And I cannot imagine how
performing placement-new from different threads on the same storage
isn't a data race.

Now, if the new expression that invokes placement-new involves
initialization, then yes, that does cause a data race with other
initializing placement-new operations on that storage. This is because
of the initialization operations conflicting by accessing the same
memory.

And while we're here, `start_lifetime_as` doesn't seem to have any
language about data races. So like... what does that mean?

-- 
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
-- Julien Villemure
Sent from my Android device with K-9 Mail.