1

Topic: Whether the code is correct

2

Re: Whether the code is correct

Hello, uzhas, you wrote: whether U> the trace Is correct. The code from the point of view of the standard? U> U>#include <iostream> U>#include <thread> U> int main () {U> std:: string x = "abc"; U> std:: cout <<"x =" <<x <<std:: endl; U> std:: thread t ([and] () {U> x = "xyz"; U>}); U> t.join (); U> std:: cout <<"x =" <<x <<std:: endl; U> return 0; U>} U> U> the access correctness to object from different flows Interests. In the given example there is no race state, therefore all in norm.

3

Re: Whether the code is correct

Hello, Kodt, you wrote: And what here can be incorrect? Visibility of new value why in main it is guaranteed new value will be visible? An example sufficient

4

Re: Whether the code is correct

Hello, Kodt, you wrote: You should find standard points? (Then wait). Or you found something causing confusion in the standard? (Then show). Basically, already : https://stackoverflow.com/questions/421 … p-on-threa https://stackoverflow.com/questions/323 … threads-li such code is considered correct thanks to that thread:: join is synch point Since thread creation and structure is defined as a synchronizing operation, joining a thread necessarily happens after that thread terminates. Thus you will see anything that necessarily happened before the thread terminated. The same is true of code that changes some variables and then creates a thread - the new thread necessarily sees all the changes that happened before it was created. Synchronization on thread creation or termination is just like synchronization on a mutex. Synchronizing operations create this kinds of ordering relationships that ensure memory visibility.

5

Re: Whether the code is correct

Hello, uzhas, you wrote: U> such code is considered correct thanks to that thread:: join the citation from n4713 is synch point: 33.3.2.5 thread members [thread.thread.member] void join (); 3 Effects: Blocks until the thread represented by *this has completed. 4 Synchronization: The completion of the thread represented by *this synchronizes with (6.8.2) the corresponding successful join () return. [Note: Operations on *this are not synchronized. - end note] and now remind me why synchronize with it is enough for visibility? For some reason it seems to me that it is not enough of it

6

Re: Whether the code is correct

Hello, uzhas, you wrote: U> and now remind me why synchronize with it is enough for visibility? For some reason it seems to me that it it is not enough here, for example, the requirement for : 5 The implementation shall provide lock and unlock operations, as described below. For purposes of determining the existence of a data race, these behave as atomic operations (6.8.2). The lock and unlock operations on a single mutex shall appear to occur in a single total order. [Note: This can be viewed as the modification order (6.8.2) of the mutex. - end note] 6 The expression m.lock () shall be well-formed and have the following semantics:..... 11 Synchronization: Prior unlock () operations on the same object shall synchronize with (6.8.2) this operation. Point 5. Much more strongly , rather than 11. Just point 5 guarantees visibility of the data after slip through lock () if the data changed under  in other flow

7

Re: Whether the code is correct

Hello, uzhas, you wrote: U> and now remind me why synchronize with it is enough for visibility? For some reason it seems to me that it I will not enough remind (including): 6 Certain library calls synchronize with other library calls performed by another thread. For example, an atomic store-release synchronizes with a load-acquire that takes its value from the store (32.4). [Note: Except in the specified cases, reading a later value does not necessarily ensure visibility as described below. Such a requirement would sometimes interfere with efficient implementation. - end note] [Note: The specifications of the synchronization operations define when one reads the value written by another. For atomic objects, the definition is clear. All operations on a given mutex occur in a s

8

Re: Whether the code is correct

uzhas: U> U> and now remind me why synchronize with it is enough for visibility? For some reason it seems to me that it is not enough of it An evaluation A inter-thread happens before an evaluation B if - A synchronizes with B, or.... An evaluation A happens before an evaluation B (or, equivalently, B happens after A) if: - A is sequenced before B, or - A inter-thread happens before B. A visible side effect A on a scalar object or bit-field M with respect to a value computation B of M satisfies the conditions: - A happens before B and - there is no other side effect X to M such that A happens before X and X happens before B. In your case is not present such X which would put between A and B.

9

Re: Whether the code is correct

Hello, uzhas, you wrote: U> and now remind me why synchronize with it is enough for visibility? For some reason it seems to me that it not enough I confused that on  release-> acquire too is synchronize with and there there is no warranty of visibility but on  actually conditional synchronize with 2 An atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and takes its value from any side effect in the release sequence headed by A..... 12 Implementations should make atomic stores visible to atomic loads within a reasonable amount of time. I transport: if in the code is load (acquire) + store (release) still is not present synchronize with. Last arises when load (acquire) sees new value. And he sees it within a reasonable amount of time a C join now it becomes clearer: If is thread.join () it hangs up and when droops, at once arises synchronize with with the flow code In the citation it is necessary to select more: 33.3.2.5 thread members [thread.thread.member] void join (); 3 Effects: Blocks until the thread represented by *this has completed. 4 Synchronization: The completion of the thread represented by *this synchronizes with (6.8.2) the corresponding successful join () return. [Note: Operations on *this are not synchronized. - end note] For  it is had the same: The expression m.lock () shall be well-formed and have the following semantics: 8 Effects: Blocks the calling thread until ownership of the mutex can be obtained for the calling thread. 9 Postconditions: The calling thread owns the mutex. 11 Synchronization: Prior unlock () operations on the same object shall synchronize with (6.8.2) this operation. Here a bit more abruptly: All unlock should be synchronize with with a call lock () Now it is necessary to estimate as from synchronize with to pass to the analysis of visibility on the basis of The value of a non-atomic scalar object or bit-field M, as determined by evaluation B, shall be the value stored by the visible side effect A in process  met the useful page: http://preshing.com/20130702/the-happen … -relation/ http://preshing.com/20130823/the-synchr … -relation/

10

Re: Whether the code is correct

11

Re: Whether the code is correct

Hello, uzhas, you wrote:> And what here can be incorrect? U> visibility of new value U> why in main it is guaranteed new value will be visible? Because is JOIN ().