Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #423 > unrolled thread

Interlocked operations, volatile

Back to article view | Back to comp.programming.threads

Contents

  Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-13 09:43 -0700
    Re: Interlocked operations, volatile Alexander Terekhov <terekhov@web.de> - 2011-07-13 20:03 +0200
    Re: Interlocked operations, volatile David Schwartz <davids@webmaster.com> - 2011-07-13 15:24 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:13 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:17 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:37 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:41 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:44 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:31 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:52 -0700
        Re: Interlocked operations, volatile David Schwartz <davids@webmaster.com> - 2011-07-14 03:06 -0700
          Re: Interlocked operations, volatile David Schwartz <davids@webmaster.com> - 2011-07-14 06:16 -0700
            Re: Interlocked operations, volatile Alexander Terekhov <terekhov@web.de> - 2011-07-14 17:20 +0200
              Re: Interlocked operations, volatile David Schwartz <davids@webmaster.com> - 2011-07-14 09:19 -0700
            Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 08:52 -0700
              Re: Interlocked operations, volatile David Schwartz <davids@webmaster.com> - 2011-07-14 10:51 -0700
                Re: Interlocked operations, volatile Alexander Terekhov <terekhov@web.de> - 2011-07-14 23:05 +0200
            Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 08:49 -0700
      Re: Interlocked operations, volatile Andrew Che <libera.ventis@gmail.com> - 2011-07-14 00:48 -0700
    Re: Interlocked operations, volatile frege <gottlobfrege@gmail.com> - 2011-07-20 22:13 -0700

#423 — Interlocked operations, volatile

Greetings!

Q1: Is it true that the only goal of using interlocked operations is
to guarantee that read/write operations are completed in proper order?
Q2: Is it true that the goal of 'volatile' is the same?
Q3: Is it nessesary to use 'int* volatile ptr' or some interlocked
operation in line [???] to be sure function2 is correct (see sample
below)?

== START SAMPLE ==

int value = 42;
int* ptr = 0;

void function1 () { // called from many threads
	cas(&ptr, &value, 0); // some compare-and-swap function
}

void function2 () { // called from many threads
	if(!ptr) { // [???]
		return;
	some_func(ptr);
}
== END SAMPLE ==


Cheers,
Andrew

[toc] | [next] | [standalone]

#424

Andrew Che wrote:
> 
> Greetings!
> 
> Q1: Is it true that the only goal of using interlocked operations is
> to guarantee that read/write operations are completed in proper order?

Not true.

> Q2: Is it true that the goal of 'volatile' is the same?

Not true.

> Q3: Is it nessesary to use 'int* volatile ptr' or some interlocked
> operation in line [???] to be sure function2 is correct (see sample
> below)?

Not necessary.

> 
> == START SAMPLE ==
> 
> int value = 42;
> int* ptr = 0;
> 
> void function1 () { // called from many threads
>         cas(&ptr, &value, 0); // some compare-and-swap function
> }
> 
> void function2 () { // called from many threads
>         if(!ptr) { // [???]
>                 return;
>         some_func(ptr);
> }
> == END SAMPLE ==
> 
> Cheers,
> Andrew

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#425

On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:

> Q1: Is it true that the only goal of using interlocked operations is
> to guarantee that read/write operations are completed in proper order?

No. The goal of interlocked operations to provide defined semantics.
We have, in general, no idea what would go wrong if we violate the
semantics. The computer could catch on fire.

> Q2: Is it true that the goal of 'volatile' is the same?

No. Again, we have no idea what might go wrong if we break the rules.
We follow the rules because they are the rules and that's the deal.
This means we don't have to figure out all the possible ways things
could go wrong if we break the rules. And, it would be impossible to
do that -- who knows what the next CPU or next version of the OS or
compiler might do?

> Q3: Is it nessesary to use 'int* volatile ptr' or some interlocked
> operation in line [???] to be sure function2 is correct (see sample
> below)?
>
> == START SAMPLE ==
>
> int value = 42;
> int* ptr = 0;
>
> void function1 () { // called from many threads
>         cas(&ptr, &value, 0); // some compare-and-swap function
>
> }
>
> void function2 () { // called from many threads
>         if(!ptr) { // [???]
>                 return;
>         some_func(ptr);}
>
> == END SAMPLE ==

It's platform dependent. If your platform provides some guarantee
without it, then you need it. If your platform doesn't provide any
guarantee even with it, then it won't help you.

DS

[toc] | [prev] | [next] | [standalone]

#427

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?



Thanks, I see.

But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (?):
----------------------------------------------------------------------------------------------------
Sematic ->	| operation on this is atomic	| ensures memory
 
|                                               |  operations follow
 
|                                               |  in certain order
---------------------------------------------------------------------------------------------------
cas			|			Yes			|            Yes
----------------------------------------------------------------------------------------------------
volatile		|			Yes			|            Yes
----------------------------------------------------------------------------------------------------

so,
Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#428

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.
But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (is ideally true?):
----------------------------------------------------------------------------------------------------
Sematic ->          | operation on this is atomic   | ensures memory
                          |
|  operations follow
                          |
|  in certain order
---------------------------------------------------------------------------------------------------
cas                     |                       Yes
|            Yes
----------------------------------------------------------------------------------------------------
volatile                |                       Yes
|            Yes
----------------------------------------------------------------------------------------------------

so,

Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#429

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.
But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.
If this table is true (really?):
----------------------------------------------------------------------------------------------------
Sematic ->   | operation on this is atomic | ensures memory operations
follow in certain order
---------------------------------------------------------------------------------------------------
cas              |               Yes                   |
Yes
---------------------------------------------------------------------------------------------------
volatile         |               Yes                   |
Yes
----------------------------------------------------------------------------------------------------
so,
Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#430

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.

But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (really?):

----------------------------------------------------------
Sematic ->   | operation | ensures memory
                   | on this    | operations
                   | is atomic | follow in
                   |               | certain order
----------------------------------------------------------
cas              |   Yes     |   Yes
----------------------------------------------------------
volatile         |   Yes     |   Yes
----------------------------------------------------------

so,

Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#431

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.

But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (really?):

---------------------------------------------------------
Sematic ->   | operation | ensures memory
                   | on this    | operations
                   | is atomic | follow in
                   |               | certain order
---------------------------------------------------------
cas              |   Yes     |   Yes
---------------------------------------------------------
volatile         |   Yes     |   Yes
---------------------------------------------------------

so,

Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#432

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.
But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.
If this table is true (really?):
----------------------------------------------------------------------------------------------------
Sematic ->   | operation on this is atomic   | ensures memory
operations follow in certain order
---------------------------------------------------------------------------------------------------
cas             |               Yes                      |
Yes
---------------------------------------------------------------------------------------------------
volatile        |               Yes                       |
Yes
----------------------------------------------------------------------------------------------------
so,
Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#433

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.

But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (really?):

---------------------------------------------------------
Sematic ->   | operation | ensures memory
             | on this   | operations
             | is atomic | follow in
             |           | certain order
---------------------------------------------------------
cas          |   Yes     |   Yes
---------------------------------------------------------
volatile     |   Yes     |   Yes
---------------------------------------------------------

so,

Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#435

On Jul 14, 12:52 am, Andrew Che <libera.ven...@gmail.com> wrote:

> Q4: What is the difference between "cas" and "volatile" for me, if I
> am just a simple programmer?

On most platforms, CAS has defined semantics for a multi-threaded
program, while volatile does not.

DS

[toc] | [prev] | [next] | [standalone]

#437

Let me clarify something important. Sometimes people get stuck in a
mode of reasoning that is incorrect. They are taught things like "you
need X or else Y can happen". Examples:

You need 'volatile' or compiler optimizations might break your code.

You need locks around concurrent accesses to variables or two read-add-
write operations might interleave leading to only one add.

It is true that there are circumstances where you need to use the
'volatile' keyword and there are circumstances where you need locks.
And it is true that if you leave out 'volatile' where it is required,
compiler optimizations might break your code. And it is true that if
you omit required locks, two read-add-write operations might result in
one add.

Nevertheless these things are false. The reason you need these things
when you do in fact need them is because the relevant standards say
so. Yes, it's also true that if you leave them out, there are known
ways in which things can go wrong. But even if we didn't know any way
they could go wrong, you would still need them. Why? Because we are
not omniscient. We are not capable of thinking of all the ways things
could go wrong. I can tell you dozens of stories of cases where code
went wrong because this "eliminate all ways it can fail" didn't cover
a way it could fail.

If your coding POSIX threads, you need CAS or mutexes or atomic
operations because POSIX says so. It is also interesting in some cases
to look at what might go wrong if you break the standard. But that's
not the reason you need the synchronization mechanisms.

DS

[toc] | [prev] | [next] | [standalone]

#438

David Schwartz wrote:
[...]
> If your coding POSIX threads, you need CAS or mutexes or atomic
> operations because POSIX says so. It is also interesting in some cases

Apart from mutexes, CAS and other atomics trigger undefined behaviour
under POSIX due to XBD 4.10.

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#441

On Jul 14, 8:20 am, Alexander Terekhov <terek...@web.de> wrote:

> David Schwartz wrote:

> > If your coding POSIX threads, you need CAS or mutexes or atomic
> > operations because POSIX says so. It is also interesting in some cases

> Apart from mutexes, CAS and other atomics trigger undefined behaviour
> under POSIX due to XBD 4.10.

Sure, and everything in POSIX triggers undefined behavior under the C
standard. So long as some standard that the platform supports
guarantees the semantics of what you're doing, you're good.

DS

[toc] | [prev] | [next] | [standalone]

#439

On Jul 14, 5:16 pm, David Schwartz <dav...@webmaster.com> wrote:
> Let me clarify something important. Sometimes people get stuck in a
> mode of reasoning that is incorrect. They are taught things like "you
> need X or else Y can happen". Examples:
>
> You need 'volatile' or compiler optimizations might break your code.
>
> You need locks around concurrent accesses to variables or two read-add-
> write operations might interleave leading to only one add.

Yes, it is quite obvious.
But what about one unlocked read might lead to multiple reads?

> It is true that there are circumstances where you need to use the
> 'volatile' keyword and there are circumstances where you need locks.
> And it is true that if you leave out 'volatile' where it is required,
> compiler optimizations might break your code. And it is true that if
> you omit required locks, two read-add-write operations might result in
> one add.
>
> Nevertheless these things are false. The reason you need these things
> when you do in fact need them is because the relevant standards say
> so. Yes, it's also true that if you leave them out, there are known
> ways in which things can go wrong. But even if we didn't know any way
> they could go wrong, you would still need them. Why? Because we are
> not omniscient. We are not capable of thinking of all the ways things
> could go wrong. I can tell you dozens of stories of cases where code
> went wrong because this "eliminate all ways it can fail" didn't cover
> a way it could fail.

Couldn't You give an (C++) example that demonstrates difference
between:
1) concurrent write with locks and read WITH locks
2) concurrent write with locks and read WITHOUT locks

I mean I would like to see a program that prints something like "a" in
case 1) and "aaaa" in case 2) because races are.

> If your coding POSIX threads, you need CAS or mutexes or atomic
> operations because POSIX says so. It is also interesting in some cases
> to look at what might go wrong if you break the standard. But that's
> not the reason you need the synchronization mechanisms.
>
> DS

P.S.: As You see all my questions are about async read and sync write.

[toc] | [prev] | [next] | [standalone]

#442

On Jul 14, 8:52 am, Andrew Che <libera.ven...@gmail.com> wrote:

> Couldn't You give an (C++) example that demonstrates difference
> between:
> 1) concurrent write with locks and read WITH locks
> 2) concurrent write with locks and read WITHOUT locks

> I mean I would like to see a program that prints something like "a" in
> case 1) and "aaaa" in case 2) because races are.

Not really. C++ provides no way to have concurrent flows of execution.
And whatever scheme we use to have concurrent flows of execution will
also include rules that prohibit concurrent write and read without
locks.

We don't need the locks to prevent a race. We need the locks because
the standard says we do.

DS

[toc] | [prev] | [next] | [standalone]

#443

David Schwartz wrote:
> 
> On Jul 14, 8:52 am, Andrew Che <libera.ven...@gmail.com> wrote:
> 
> > Couldn't You give an (C++) example that demonstrates difference
> > between:
> > 1) concurrent write with locks and read WITH locks
> > 2) concurrent write with locks and read WITHOUT locks
> 
> > I mean I would like to see a program that prints something like "a" in
> > case 1) and "aaaa" in case 2) because races are.
> 
> Not really. C++ provides no way to have concurrent flows of execution.

Upcomming C++11 does provide threading...

> And whatever scheme we use to have concurrent flows of execution will
> also include rules that prohibit concurrent write and read without
> locks.

... and atomics (concurrent write and read without locks allowed).

regards,
alexander.

[toc] | [prev] | [next] | [standalone]

#440

On Jul 14, 5:16 pm, David Schwartz <dav...@webmaster.com> wrote:
> Let me clarify something important. Sometimes people get stuck in a
> mode of reasoning that is incorrect. They are taught things like "you
> need X or else Y can happen". Examples:
>
> You need 'volatile' or compiler optimizations might break your code.
>
> You need locks around concurrent accesses to variables or two read-add-
> write operations might interleave leading to only one add.

Yes, it is quite obvious.
But what about one unlocked read might lead to multiple reads?

> It is true that there are circumstances where you need to use the
> 'volatile' keyword and there are circumstances where you need locks.
> And it is true that if you leave out 'volatile' where it is required,
> compiler optimizations might break your code. And it is true that if
> you omit required locks, two read-add-write operations might result in
> one add.
>
> Nevertheless these things are false. The reason you need these things
> when you do in fact need them is because the relevant standards say
> so. Yes, it's also true that if you leave them out, there are known
> ways in which things can go wrong. But even if we didn't know any way
> they could go wrong, you would still need them. Why? Because we are
> not omniscient. We are not capable of thinking of all the ways things
> could go wrong. I can tell you dozens of stories of cases where code
> went wrong because this "eliminate all ways it can fail" didn't cover
> a way it could fail.

Couldn't You give an (C++) example that demonstrates difference
between:
1) concurrent write with locks and read WITH locks
2) concurrent write with locks and read WITHOUT locks

I mean I would like to see a program that prints something like "a" in
case 1) and "aaaa" in case 2) because races are.

> If your coding POSIX threads, you need CAS or mutexes or atomic
> operations because POSIX says so. It is also interesting in some cases
> to look at what might go wrong if you break the standard. But that's
> not the reason you need the synchronization mechanisms.
>
> DS

P.S.: As You see all my questions are about async read and sync write.

[toc] | [prev] | [next] | [standalone]

#434

On Jul 14, 2:24 am, David Schwartz <dav...@webmaster.com> wrote:
> On Jul 13, 9:43 am, Andrew Che <libera.ven...@gmail.com> wrote:
>
> > Q1: Is it true that the only goal of using interlocked operations is
> > to guarantee that read/write operations are completed in proper order?
>
> No. The goal of interlocked operations to provide defined semantics.
> We have, in general, no idea what would go wrong if we violate the
> semantics. The computer could catch on fire.
>
> > Q2: Is it true that the goal of 'volatile' is the same?
>
> No. Again, we have no idea what might go wrong if we break the rules.
> We follow the rules because they are the rules and that's the deal.
> This means we don't have to figure out all the possible ways things
> could go wrong if we break the rules. And, it would be impossible to
> do that -- who knows what the next CPU or next version of the OS or
> compiler might do?

Thanks, I see.

But let us imagine ideal CPU and ideal OS that support semantic and
rules you mean.

If this table is true (really?):

---------------------------------------------------------
Sematic ->   | operation | ensures memory
             | on this   | operations
             | is atomic | follow in
             |           | certain order
---------------------------------------------------------
cas          |   Yes     |   Yes
---------------------------------------------------------
volatile     |   Yes     |   Yes
---------------------------------------------------------

so,

Q4: What is the difference between "cas" and "volatile" for me, if I
am just a simple programmer?

[toc] | [prev] | [next] | [standalone]

#468

On Jul 13, 12:43 pm, Andrew Che <libera.ven...@gmail.com> wrote:
> Greetings!
>
> Q1: Is it true that the only goal of using interlocked operations is
> to guarantee that read/write operations are completed in proper order?
> Q2: Is it true that the goal of 'volatile' is the same?
> Q3: Is it nessesary to use 'int* volatile ptr' or some interlocked
> operation in line [???] to be sure function2 is correct (see sample
> below)?
>
> == START SAMPLE ==
>
> int value = 42;
> int* ptr = 0;
>
> void function1 () { // called from many threads
>         cas(&ptr, &value, 0); // some compare-and-swap function
>
> }
>
> void function2 () { // called from many threads
>         if(!ptr) { // [???]
>                 return;
>         some_func(ptr);}
>
> == END SAMPLE ==
>
> Cheers,
> Andrew

volatile and threads should get a divorce.  In fact, the truth is,
they were never married, it was only a rumour.  volatile was rarely
useful with threads, and even more rarely sufficient (ie you need more
than volatile) - and that was all non-standard. In C++0x we will
finally get threads as part of the language, and we can more clearly
remove volatile from threading code - because volatile is basically
for memory "outside" the realm of the "abstract machine" that the
standard lives in.  With threads inside that standard, it becomes
clear that volatile isn't for threads.

In your example, *one way* things could go wrong is that some thread/
CPU 'sees' the new value of 'ptr', but doesn't see a new value for
'value'. (I assume the value of 'value' changes?)  So assuming
'some_func(ptr)' actually reads what is being pointed to, it might not
read the value you are expecting.  This could be for at least 2
reasons - your version of 'cas()' doesn't guarantee any ordering, or
(more likely) your read of 'ptr' in 'if(!ptr)' doesn't guarantee any
order of the read of '*ptr'.  The read of '*ptr' can happen before the
read of 'ptr'.  Yes really.

But like David alluded to, this is just *one way* that things could go
wrong.  Unless you follow some rules that are guaranteed by your
environment, then anything could go wrong.  And if you do follow the
rules, than nothing can go wrong.  So follow some rules.  Which ones
do you have at your disposal? - POSIX? Windows? C++0x?

Tony

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web