celix-commits mailing list archives

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

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

Bjoern Petri commented on CELIX-233:

Gerrit, it is clear that critical sections needs to be protected. The problem I am questing
here is whether we can get into trouble because boolean variables neither act as memory barriers
nor are there protected against re-ordering as a result of compiler optimizations. That's
why I was wondering whether we can get intro trouble

*  due to a missing memory barrier leading to a thread using already invalidated data. 
*  due to an out of order execution leading to a thread using invalidated data before the
global  variable indicates to stop.

First, problems with memory visibility seem to be easily solvable by either using 'volatile'
or ensuring that a thread just don't using invalid data (e.g. pthread_join after setting threadRunning=false
and before invalidating data). But latter can only be solved by using of mutexes (see also
http://stackoverflow.com/a/2485177/4354534) . 

Are you aware of this? Do you think that's negligible for us?

> 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

View raw message