Question about store and clfush for Persistent Memory Programming.

[onceltl]

struct rectangle {

uint64_t x = 0;

uint64_t y = 0;

uint64_t dummy[6];

};

int rect_construct(PMEMobjpool *pop, struct rectangle *rect) 

{

rect->y = 10;

rect->x = 5;

pmemobj_persist(pop, rect, sizeof *rect);

return 0;

}

Hi all !

    I have some questions about the above code.   When executing rect_construct funtion，system crashes.  

    Assuming that the architecture is x86, x and y are in the same cacheline. 

   Obviously, the value recorded on PM may be（x=5，y=10) , or（x=0，y=0), or (x=0,y=10).

    Is it possible to cause (x=5, y = 0)?  It is said that x86-TSO can guarantee that this will not happen,I'm not sure.

Thanks!

[ppbb...@gmail.com]

This example is correct in the context of libpmemobj because the memory allocator guarantees that constructors are all-or-nothing. You won't ever see an allocated object with a partially executed constructor.

Outside of a libpmemobj allocator, this code can produce four different variants of (y,x): (0,0), (0, 5), (10, 0), (10, 5), more if the assignments are not done with 8-byte stores. There's no guarantee of cache-line write atomicity.

[onceltl]

Thanks! 

Maybe I didn't describe it clearly. During the time I was waiting for a reply, I found some related discussions. please to see https://github.com/pmem/pmdk/issues/4713 and  https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/pmem/R8H3sKq9sLQ.

In their example, the following code is used：

/* assume the cache line starts off containing zeros */

buff[0] = 1

buff[8] = 1

CLWB buff

SFENCE

The conclusion is that three situations will be caused after the system crashes ：

     · buff[0] is 1, buff[8]  is  0

     · both buff[0] and buff[8] are 0  

     ·buff[1] are 1.  

It is not possible for buff[8] to be 1 and buff[0] to be 0.

In my example, I swapped the order of stores：

buff[8] = 1

buff[0] = 1

CLWB buff

SFENCE

Is it  possible for buff[0] to be 1 and buff[8] to be 0?

在 2020年7月30日星期四 UTC+8下午4:40:57，ppbb...@gmail.com写道：

[ppbb...@gmail.com]

Right, I didn't notice this, it was a trick question :D

I believe what's important is the order of stores within the same cache line, not the absolute addresses. So yes, I think you are right. As far as I can tell, the buff[0] = 1, buff[8] = 0 scenario does not seem possible.

Piotr

[onceltl]

Thanks for  solving the trouble comfusing me quite a while.

在 2020年7月30日星期四 UTC+8下午5:33:33，ppbb...@gmail.com写道：