volatile bool

  • Thread starter Thread starter Peter Morris
  • Start date Start date
P

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?
 
Peter said:
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?
Click to expand...
I'm guessing he is either using or was planning on using the Interlocked
methods. Those don't operate on bools.
 
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?
Click to expand...

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)?
 
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.
 
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?
Click to expand...

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 :-)
 
Peter said:
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?
Click to expand...

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
 
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?
 
Peter said:
That's the entire definition :-)
Click to expand...

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
 
But if it were int more states could be added and the
test could be changed without effecting the client code.
Click to expand...

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.
Click to expand...

Hopefully he will reply. I expect it is just a mistake, but you never know
:-)
 
G.S. said:
Can it be because he may need more than two states?
Click to expand...

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
 
Peter said:
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.
Click to expand...

There could be other code that were public.
Hopefully he will reply. I expect it is just a mistake, but you never
know :-)
Click to expand...

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

Arne
 
Back
Top