volatile bool

[Peter Morris]

I'm reading Joe Duffy's book "Concurrent Programming on Windows" (highly
recommended by the way!).

I am surprised by the following code in a class

private volatile int m_Completed; //0==Not complete, 1==Complete
public bool IsCompleted
{
get { return m_Completed == 1; }
}

I'd have been inclined to use "private volatile bool". This leads me to
believe there must be a problem with volatile booleans? Surely writing to a
boolean is a single CPU cycle just as it is with writing an int? So why
would he do it this way? What don't I know?

 

[Jeroen Mostert]

I'm reading Joe Duffy's book "Concurrent Programming on Windows" (highly
recommended by the way!).

I am surprised by the following code in a class

private volatile int m_Completed; //0==Not complete, 1==Complete
public bool IsCompleted
{
get { return m_Completed == 1; }
}

I'd have been inclined to use "private volatile bool". This leads me to
believe there must be a problem with volatile booleans? Surely writing
to a boolean is a single CPU cycle just as it is with writing an int?
So why would he do it this way? What don't I know?

I'm guessing he is either using or was planning on using the Interlocked
methods. Those don't operate on bools.

 

[Pavel Minaev]

I'm reading Joe Duffy's book "Concurrent Programming on Windows" (highly
recommended by the way!).

I am surprised by the following code in a class

    private volatile int m_Completed; //0==Not complete, 1==Complete
    public bool IsCompleted
    {
        get { return m_Completed == 1; }
    }

I'd have been inclined to use "private volatile bool".  This leads me to
believe there must be a problem with volatile booleans?  Surely writingto a
boolean is a single CPU cycle just as it is with writing an int?  So why
would he do it this way?  What don't I know?

The spec guarantees atomicity for bools just as it does that for ints,
and aside from that I don't see any possible problems with volatile
bool. In fact, C# language specification section about "volatile"
actually has a code snippet with "volatile bool" in it (http://
msdn.microsoft.com/en-us/library/aa645755.aspx).

No idea why the author wasn't straightforward here. Might be some
(incorrect) assumptions from past C/C++ experience (though even there
I can't think of any problems)?

 

[William Stacey]

I would guess that is the reason also. I seem to recall some of his other
stuff that used int this way because needing to use interlock.

 

[Peter Morris]

I've emailed the author to ask. I will post the answer

 

[G.S.]

I'm reading Joe Duffy's book "Concurrent Programming on Windows" (highly
recommended by the way!).

I am surprised by the following code in a class

    private volatile int m_Completed; //0==Not complete, 1==Complete
    public bool IsCompleted
    {
        get { return m_Completed == 1; }
    }

I'd have been inclined to use "private volatile bool".  This leads me to
believe there must be a problem with volatile booleans?  Surely writingto a
boolean is a single CPU cycle just as it is with writing an int?  So why
would he do it this way?  What don't I know?

Can it be because he may need more than two states?

I will say, as a disclaimer, that I know nothing about the subject
matter, nor the usage of this particular snippet

 

[Jeff Gaines]

Can it be because he may need more than two states?

true, false and 'I read on the Internet'

 

[Peter Morris]

Can it be because he may need more than two states?

That's the entire definition

 

[Alun Harford]

I'm reading Joe Duffy's book "Concurrent Programming on Windows" (highly
recommended by the way!).

I am surprised by the following code in a class

private volatile int m_Completed; //0==Not complete, 1==Complete
public bool IsCompleted
{
get { return m_Completed == 1; }
}

I'd have been inclined to use "private volatile bool". This leads me to
believe there must be a problem with volatile booleans? Surely writing
to a boolean is a single CPU cycle just as it is with writing an int?
So why would he do it this way? What don't I know?

On the CLR, bools are just Int32s really anyway (the fact that
collections of bools use 4x as much memory as a collections of bytes is
a nice bit of trivia). See ECMA-335 for more details.

Alun Harford

 

[Peter Morris]

On the CLR, bools are just Int32s really anyway

Which merely serves to explain why using int instead of bool is pointless
when you could use bool and make your code more obvious, don't you think?

 

[Arne Vajhøj]

That's the entire definition

Now.

But if it were int more states could be added and the
test could be changed without effecting the client code.

Pure guess work of course.

He also just have been coding a lot in a language without
boolean type.

Arne

 

[Peter Morris]

But if it were int more states could be added and the

test could be changed without effecting the client code.

It doesn't hold water I am afraid

The "int" is private, so you can change it to whatever you like without
affecting client code. The "bool" is public.

He also just have been coding a lot in a language without
boolean type.

Hopefully he will reply. I expect it is just a mistake, but you never know

 

[Rudy Velthuis]

Can it be because he may need more than two states?

In that case, I would use an enum. That would give him the opportunity
to give his states nice and clear names.

--
Rudy Velthuis http://rvelthuis.de

"I know that there are people in this world who do not love
their fellow human beings, and I hate people like that."
-- Tom Lehrer

 

[Arne Vajhøj]

It doesn't hold water I am afraid

The "int" is private, so you can change it to whatever you like without
affecting client code. The "bool" is public.

There could be other code that were public.

Hopefully he will reply. I expect it is just a mistake, but you never
know

It very likely is. Real code are not perfect there are always
"something". Perfect code is never completed.

Arne