celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pepijn Noltes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CELIX-233) Replace booleans as sync primitives
Date Tue, 19 May 2015 10:28:00 GMT

    [ https://issues.apache.org/jira/browse/CELIX-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14550200#comment-14550200
] 

Pepijn Noltes commented on CELIX-233:
-------------------------------------

Hi,

The stackoverflow page mentioned by Bjorn refers to an article (http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf).
This is the article where I understood that using volatile is not needed to ensure you read
the last written value,  as long as you don't use value from the registry (e.g. no local value
in the function). 

Note that this does not protect for out of order execution. 
But in this case this should not be a problem; We don't increment a value only set a specific
value and waiting for thread (join) before the boolean is changed is no issue as long as the
boolean will change.  

That being said, I cannot find any reliable info about this and this only applies for "modern
cpu's". So maybe a more "standard" approach is preferable. 

> Replace booleans as sync primitives
> -----------------------------------
>
>                 Key: CELIX-233
>                 URL: https://issues.apache.org/jira/browse/CELIX-233
>             Project: Celix
>          Issue Type: Bug
>            Reporter: Bjoern Petri
>            Assignee: Bjoern Petri
>
> In a lot of cases we use boolean variables (e.g. bool running) to determine whether a
critical section can be executed. Usually those variables are not declared volatile, so the
they may be cached in registers. Before the value in the register is written to memory, another
thread might be scheduled to run, resulting in that thread reading stale data.
> But even when declaring a variable as volatile (although the volatile qualifier guarantees
that the reads and writes will happen in the exact order specified in the source code), the
compiler may generate code which reorders a volatile read or write with non-volatile reads
or writes, thus limiting its usefulness as an interthread flag or mutex.
> That's why it should be preferable to use e.g. a mutex as sync primitive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message