Date: Tue, 20 Dec 2022 20:01:30 -0500
> calling "the library versions of
operator new" is not a data race
This only apply to the allocation/deallocation functions named "operator new"/"operator delete", it doesn't say anything about "new expression" (which is not the same as the allocation functions named "operator new"). It simply states that multiple threads can allocate memory without the need to use synchronization primitives, calls to operator new and operator delete occur in a single total order, in particular two successive calls to operator new without an intervening call to operator delete are guaranteed to never return addresses to overlapping bytes.
Furthermore, the placement version of operator new, that is `void* operator new(std::size_t count, void* ptr)`
is a noop:
> 9) Called by the standard single-object placement new expression. The standard library implementation performs no action and returns ptr unmodified. The behavior is undefined if this function is called through a placement new expression and ptr is a null pointer.
The documented behavior makes it trivially thread safe without any need for synchronization primitives.
cheers,
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?
operator new" is not a data race
This only apply to the allocation/deallocation functions named "operator new"/"operator delete", it doesn't say anything about "new expression" (which is not the same as the allocation functions named "operator new"). It simply states that multiple threads can allocate memory without the need to use synchronization primitives, calls to operator new and operator delete occur in a single total order, in particular two successive calls to operator new without an intervening call to operator delete are guaranteed to never return addresses to overlapping bytes.
Furthermore, the placement version of operator new, that is `void* operator new(std::size_t count, void* ptr)`
is a noop:
> 9) Called by the standard single-object placement new expression. The standard library implementation performs no action and returns ptr unmodified. The behavior is undefined if this function is called through a placement new expression and ptr is a null pointer.
The documented behavior makes it trivially thread safe without any need for synchronization primitives.
cheers,
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.
Received on 2022-12-21 01:01:38