memory-model

Does a correctly synchronized program still allow data race?(Part I)

北城余情 提交于 2019-11-27 07:04:51
问题 There are two conclusions from JLS: C1: If a program is free of data races, then all executions of the program will appear to be sequentially consistent: data-race-free => sequentially consistent C2: If a program is correctly synchronized, then all executions of the program will appear to be sequentially consistent: correctly synchronized => sequentially consistent If the converse of C1 is true, then we can conclude that: C3: If a program is correctly synchronized, then it is free of data

What is the scope of memory flushed or published to various threads when using volatile and synchronized?

瘦欲@ 提交于 2019-11-27 02:21:02
问题 This question is in reference to memory visibility only, not happens-before and happens-after. There are four ways in Java that guarantees changes to memory in one thread to be made visible to another thread. (reference http://gee.cs.oswego.edu/dl/cpj/jmm.html) A writing thread releases a synchronization lock and a reading thread subsequently acquires that same synchronization lock. If a field is declared as volatile, any value written to it is flushed and made visible by the writer thread

Will two relaxed writes to the same location in different threads always be seen in the same order by other threads?

狂风中的少年 提交于 2019-11-27 02:12:06
问题 On the x86 architecture, stores to the same memory location have a total order, e.g., see this video. What are the guarantees in the C++11 memory model? More precisely, in -- Initially -- std::atomic<int> x{0}; -- Thread 1 -- x.store(1, std::memory_order_release); -- Thread 2 -- x.store(2, std::memory_order_release); -- Thread 3 -- int r1 = x.load(std::memory_order_acquire); int r2 = x.load(std::memory_order_acquire); -- Thread 4 -- int r3 = x.load(std::memory_order_acquire); int r4 = x.load

Acquire/release semantics with 4 threads

泄露秘密 提交于 2019-11-27 01:50:20
问题 I am currently reading C++ Concurrency in Action by Anthony Williams. One of his listing shows this code, and he states that the assertion that z != 0 can fire. #include <atomic> #include <thread> #include <assert.h> std::atomic<bool> x,y; std::atomic<int> z; void write_x() { x.store(true,std::memory_order_release); } void write_y() { y.store(true,std::memory_order_release); } void read_x_then_y() { while(!x.load(std::memory_order_acquire)); if(y.load(std::memory_order_acquire)) ++z; } void

Where can I find good, solid documentation for the C++0x synchronization primitives? [closed]

此生再无相见时 提交于 2019-11-27 01:40:55
问题 I've seen articles on ::std::thread and ::std::forward and such, but I have seen no good articles on ::std::atomic . There is, of course, the standards proposal paper, but I haven't seen any good documentation for someone who just wanted to use the facility. Is there any? Where can I find it? 回答1: The just::thread library has decent documentation and was developed by Anthony Williams, author of C++ Concurrency in Action and maintainer of the Boost thread library. 回答2: There's also the C++

C++0x memory model and speculative loads/stores

こ雲淡風輕ζ 提交于 2019-11-27 00:37:15
问题 So I was reading about the memory model that is part of the upcoming C++0x standard. However, I'm a bit confused about some of the restrictions for what the compiler is allowed to do, specifically about speculative loads and stores. To start with, some of the relevant stuff: Hans Boehm's pages about threads and the memory model in C++0x Boehm, "Threads Cannot be Implemented as a Library" Boehm and Adve, "Foundations of the C++ Concurrency Memory Model" Sutter, "Prism: A Principle-Based

Is Dalvik's memory model the same as Java's?

|▌冷眼眸甩不掉的悲伤 提交于 2019-11-27 00:06:25
Is Dalvik's memory model the same as Java's ? I am particularly interested in whether reads and writes of reference and non- long /non- double primitive variables are atomic, but I would also like to know whether there are any differences between the two platforms' memory models. As of 4.0 (Ice Cream Sandwich), Dalvik's behavior should match up with JSR-133 (the Java Memory Model). As of 3.0 (Honeycomb), most of the pieces were in place, but some minor things had been overlooked that would be difficult to encounter in practice (e.g. some edge cases in finalization). As of 2.3 (Gingerbread),

Java - is volatile required with synchronized?

橙三吉。 提交于 2019-11-26 23:36:58
问题 In the following simple scenario: class A { int x; Object lock; ... public void method(){ synchronized(lock){ // modify/read x and act upon its value } } } Does x need to be volatile? I know that synchronized guarantees atomicity, but I am not sure about visibility though... does lock -> modify -> unlock -> lock guarantee, that after the second lock the value of x will be "fresh"? 回答1: No it does not, synchronised already has a memory barrier inserted after it, so all Threads will see the

Is it possible to observe a partially-constructed object from another thread?

北城以北 提交于 2019-11-26 22:47:50
问题 I've often heard that in the .NET 2.0 memory model, writes always use release fences. Is this true? Does this mean that even without explicit memory-barriers or locks, it is impossible to observe a partially-constructed object (considering reference-types only) on a thread different from the one on which it is created? I'm obviously excluding cases where the constructor leaks the this reference. For example, let's say we had the immutable reference type: public class Person { public string

Peterson algorithm in Java?

依然范特西╮ 提交于 2019-11-26 22:46:12
问题 Is there example implementation of Peterson algorithm for mutual exclusion in Java? 回答1: No one here has provided a correct/safe implementation of this algorithm in Java. I'm not sure how John W's solution is supposed to work since it's got pieces missing (namely the declarations of the ThreadLocals and an explanation of what is supposed to be in his array—primitive booleans don't have get() and set() ). Chapter 17 of the Java Language Specification explains the Java memory model. Of