Skipping synchronization for pre-reading

[Slawomir Pryczek]

Hi Guys,

im thinknig about "garbage" collection algorithm that'll scan the memory that needs to be collected looking for expired items. The idea is to scan the memory that is being constantly written to, without locking, then after a potential expired item is found, use mutex to be sure that the value that is read is actually correct. Something like "double-read".

Example from line 24. It doesn't work in playground, only when compiled, of course race detector goes crazy.

https://play.golang.org/p/vF4P0kyRrx

I read that it is generally not advised to do that, can i corrupt eg. CPU cache this way, so after locking i'll still get "incorrect" value that is corrupted? Is there any potential problem with that approach, in C / Golang? Any way to "tell" race detector to be silent for some vars.

Thanks.

[Dmitry Vyukov]

Use sync/atomic operations for unprotected reads and for writes to the
variable. Then it becomes a legal pattern.

[Dave Cheney]

This is double checked locking, http://en.wikipedia.org/wiki/Double-checked_locking. It is generally considered unsafe.

[Slawomir Pryczek]

Yes i read the Java examples about singleton pattern and pre-checking ... understand why it might be unsafe, probably because the pointer could be not null but still partially written to and returned. I have a little different situation, i mean the data is double checked before it is used, instead of checking before generation...

JAVA singleton sample:

if not null return

lock

if null generate

unlock 

return

My code:

if not expired, return [skip]

if expired lock

if still expired delete

unlock

So the first code isn't 100% safe because write to pointer could not be atomic in C (if i get that correctly)... problem with second example would be CPU cache corruption or some compiler optimization...

Any more comments on that?

Thanks.

[Egon]

On Tuesday, 21 April 2015 17:46:57 UTC+3, Slawomir Pryczek wrote:

Yes i read the Java examples about singleton pattern and pre-checking ... understand why it might be unsafe, probably because the pointer could be not null but still partially written to and returned. I have a little different situation, i mean the data is double checked before it is used, instead of checking before generation...

JAVA singleton sample:

if not null return

lock

if null generate

unlock 

return

My code:

if not expired, return [skip]

if expired lock

if still expired delete

unlock

So the first code isn't 100% safe because write to pointer could not be atomic in C (if i get that correctly)... problem with second example would be CPU cache corruption or some compiler optimization...

Any more comments on that?

https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong