Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Newbie question: accessing global variable on multiprocessor (http://www.velocityreviews.com/forums/t711176-newbie-question-accessing-global-variable-on-multiprocessor.html)

amit 01-08-2010 11:09 PM

Newbie question: accessing global variable on multiprocessor
 
Hello friends,

If there's a global variable - to be accessed (read/written) by multiple
threads (on multiprocessor), then any correctly implemented access (of
that variable) will cause complete cache reload of all CPUs - is that
true or not? Anyway, what would be the cost (as compared to single read/
write instruct

I'm not talking about locking here - I'm talking about all threads seeing
the most recent value of that variable.

Thanks,

amit 01-08-2010 11:28 PM

Re: Newbie question: accessing global variable on multiprocessor
 
amit writes:
> Hello friends,
>
> If there's a global variable - to be accessed (read/written) by multiple
> threads (on multiprocessor), then any correctly implemented access (of
> that variable) will cause complete cache reload of all CPUs - is that
> true or not? Anyway, what would be the cost (as compared to single read/
> write instruct
>
> I'm not talking about locking here - I'm talking about all threads
> seeing the most recent value of that variable.
>
> Thanks,


*bump*

anyone in this chatroom?

Ian Collins 01-08-2010 11:35 PM

Re: Newbie question: accessing global variable on multiprocessor
 
amit wrote:
> amit writes:
>> Hello friends,
>>
>> If there's a global variable - to be accessed (read/written) by multiple
>> threads (on multiprocessor), then any correctly implemented access (of
>> that variable) will cause complete cache reload of all CPUs - is that
>> true or not? Anyway, what would be the cost (as compared to single read/
>> write instruct
>>
>> I'm not talking about locking here - I'm talking about all threads
>> seeing the most recent value of that variable.
>>
>> Thanks,

>
> *bump*
>
> anyone in this chatroom?


Which chat room?

--
Ian Collins

Keith Thompson 01-08-2010 11:41 PM

Re: Newbie question: accessing global variable on multiprocessor
 
amit <nospam@nospam.com> writes:
> amit writes:
>> If there's a global variable - to be accessed (read/written) by multiple
>> threads (on multiprocessor), then any correctly implemented access (of
>> that variable) will cause complete cache reload of all CPUs - is that
>> true or not? Anyway, what would be the cost (as compared to single read/
>> write instruct
>>
>> I'm not talking about locking here - I'm talking about all threads
>> seeing the most recent value of that variable.
>>
>> Thanks,

>
> *bump*
>
> anyone in this chatroom?


This is not a chatroom, it's a newsgroup. If you got a response
within 19 minutes, you'd be very lucky. If you don't see anything
within a day or two, you can start to wonder. You can think of it,
very loosely, as a kind of distributed e-mail; people will see your
posts when they get around to checking the newsgroup, not as soon
as you send them. There are also some delays imposed by propagation
from one server to another.

Standard C doesn't support threads. (The draft of the new
standard adds threading support, but it won't be relevant to
programmers for quite a few years.) You'll get better answers
in comp.programming.threads. I suggest browsing that newsgroup's
archives and/or checking its FAQ first.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Rui Maciel 01-09-2010 01:21 AM

Re: Newbie question: accessing global variable on multiprocessor
 
amit wrote:

> Hello friends,
>
> If there's a global variable - to be accessed (read/written) by multiple
> threads (on multiprocessor), then any correctly implemented access (of
> that variable) will cause complete cache reload of all CPUs - is that
> true or not? Anyway, what would be the cost (as compared to single read/
> write instruct
>
> I'm not talking about locking here - I'm talking about all threads seeing
> the most recent value of that variable.


You will get better replies if you post your question on a newsgroup dedicated to
parallel programming, such as comp.programming.threads.


Hope this helps,
Rui Maciel

BGB / cr88192 01-09-2010 05:50 AM

Re: Newbie question: accessing global variable on multiprocessor
 

"amit" <nospam@nospam.com> wrote in message
news:hi8dvk$9qd$1@speranza.aioe.org...
> Hello friends,
>
> If there's a global variable - to be accessed (read/written) by multiple
> threads (on multiprocessor), then any correctly implemented access (of
> that variable) will cause complete cache reload of all CPUs - is that
> true or not? Anyway, what would be the cost (as compared to single read/
> write instruct
>
> I'm not talking about locking here - I'm talking about all threads seeing
> the most recent value of that variable.
>


well, this is not strictly standard C, but a few things go here:
the CPU is smart enough, it will not flush "all caches" on access, but would
instead only flush those which are relevant, and typically only on write
(for the other processors);
the functionality for this is built into the CPU's and the bus, so nothing
particularly special is needed.

note that, for shared variables, you would want to mark them 'volatile'
(this is a keyword which serves this purpose, among others). basically, this
just tells the compiler to read from and write changes directly to memory,
rather than have them likely sit around in a register somewhere.

as for the cost, in itself it is usually fairly small.


there are also atomic/bus-locking operations, which are usually used for
implementing mutexes, but are not usually needed for most data structures.



lacos@ludens.elte.hu 01-09-2010 06:02 PM

Re: Newbie question: accessing global variable on multiprocessor
 
In article <hi95ef$4qc$1@news.albasani.net>, "BGB / cr88192" <cr88192@hotmail.com> writes:
> "amit" <nospam@nospam.com> wrote in message
> news:hi8dvk$9qd$1@speranza.aioe.org...
>> Hello friends,
>>
>> If there's a global variable - to be accessed (read/written) by multiple
>> threads (on multiprocessor), then any correctly implemented access (of
>> that variable) will cause complete cache reload of all CPUs - is that
>> true or not? Anyway, what would be the cost (as compared to single read/
>> write instruct
>>
>> I'm not talking about locking here - I'm talking about all threads seeing
>> the most recent value of that variable.
>>

>
> well, this is not strictly standard C, but a few things go here:
> the CPU is smart enough, it will not flush "all caches" on access, but would
> instead only flush those which are relevant, and typically only on write
> (for the other processors);
> the functionality for this is built into the CPU's and the bus, so nothing
> particularly special is needed.
>
> note that, for shared variables, you would want to mark them 'volatile'
> (this is a keyword which serves this purpose, among others). basically, this
> just tells the compiler to read from and write changes directly to memory,
> rather than have them likely sit around in a register somewhere.


I sincerely believe that you're wrong. This is a very frequent fallacy
(I hope I'm using the right word). volatile in C has nothing to do with
threads. Volatile is what the standard defines it to be. See

http://www.open-std.org/JTC1/sc22/wg...006/n2016.html

The question is interesting and relevant (if perhaps not topical in this
newsgroup). I was waiting for somebody to give "amit" an answer. Off the
top of my head:

- The new C++ standard will have atomic<type> which seems to be exactly
what amit needs.

- The CPU is absolutely not smart enough to find out what you need. The
compiler and the CPU may jointly and aggressively reorder the machine
level loads and stores that one would naively think to be the direct
derivation of his/her C code. Memory barriers are essential and the
POSIX threads implementations do utilize them.

To substantiate (or fix) these claims, a few links:

http://www.hpl.hp.com/personal/Hans_...eadsintro.html
http://bartoszmilewski.wordpress.com...cation-safety/
http://bartoszmilewski.wordpress.com...ces-on-an-x86/
http://bartoszmilewski.wordpress.com...l-consistency/
http://bartoszmilewski.wordpress.com...mory-ordering/

I'm obviously not in the position to give advice to anybody here.
Nonetheless, my humble suggestion for the interested is to read all of
the writings linked to above. For me personally, the conclusion was to
avoid both unsychnronized and not explicitly synchronized access like
the plague.

Cheers,
lacos

Nobody 01-10-2010 07:20 AM

Re: Newbie question: accessing global variable on multiprocessor
 
On Sat, 09 Jan 2010 19:02:38 +0100, lacos wrote:

>> note that, for shared variables, you would want to mark them 'volatile'
>> (this is a keyword which serves this purpose, among others). basically, this
>> just tells the compiler to read from and write changes directly to memory,
>> rather than have them likely sit around in a register somewhere.

>
> I sincerely believe that you're wrong. This is a very frequent fallacy
> (I hope I'm using the right word). volatile in C has nothing to do with
> threads. Volatile is what the standard defines it to be. See


Notably, the standard states that reading from a "volatile" variable is a
sequence point, while reading from non-volatile variables isn't.

The more significant issue is that a sequence point isn't necessarily what
people expect. The specification only describes the *abstract* semantics,
which doesn't have to match what actually occurs at the hardware level.

AFAIK, there are only two situations where you can say "if this variable
is declared "volatile", this code will behave in this way; if you omit the
qualifier, it's undefined or implementation-defined behaviour". One
case relates to setjmp()/longjmp(), the other to signal().

And even if the compiler provides the "assumed" semantics for "volatile"
(i.e. it emits object code in which read/write of volatile variables
occurs in the "expected" order), that doesn't guarantee that the processor
itself won't re-order the accesses.


Flash Gordon 01-10-2010 11:06 AM

Re: Newbie question: accessing global variable on multiprocessor
 
Nobody wrote:
> On Sat, 09 Jan 2010 19:02:38 +0100, lacos wrote:
>
>>> note that, for shared variables, you would want to mark them 'volatile'
>>> (this is a keyword which serves this purpose, among others). basically, this
>>> just tells the compiler to read from and write changes directly to memory,
>>> rather than have them likely sit around in a register somewhere.

>> I sincerely believe that you're wrong. This is a very frequent fallacy
>> (I hope I'm using the right word). volatile in C has nothing to do with
>> threads. Volatile is what the standard defines it to be. See

>
> Notably, the standard states that reading from a "volatile" variable is a
> sequence point, while reading from non-volatile variables isn't.


C&V? I don't think reading from a volatile is a sequence point.

> The more significant issue is that a sequence point isn't necessarily what
> people expect. The specification only describes the *abstract* semantics,
> which doesn't have to match what actually occurs at the hardware level.


At this point, it is worth noting that there is a relationship between
volatile and sequence points. I believe the language for this is being
tidied up in the next version of the C standard, but since
reading/writing a volatile object is a side effect it has to be complete
before the sequence point.

> AFAIK, there are only two situations where you can say "if this variable
> is declared "volatile", this code will behave in this way; if you omit the
> qualifier, it's undefined or implementation-defined behaviour". One
> case relates to setjmp()/longjmp(), the other to signal().


For signal it needs to be volatile sig_atomic_t.

> And even if the compiler provides the "assumed" semantics for "volatile"
> (i.e. it emits object code in which read/write of volatile variables
> occurs in the "expected" order), that doesn't guarantee that the processor
> itself won't re-order the accesses.


However, it does have to document what it means by accessing a volatile,
and it should be possible to identify from this whether it prevents the
processor from reordering further down, whether it bypasses the cache etc.

In short, volatile seems like a sensible thing to specify on objects
accessed by multiple threads, but definitely is NOT guaranteed to be
sufficient, and may not be necessary. It's something where you need to
read the documentation for your implementation, and it may depend on
whether you have multiple cores on one processor, multiple separate
processors, and how the HW is designed.
--
Flash Gordon

Nobody 01-10-2010 03:47 PM

Re: Newbie question: accessing global variable on multiprocessor
 
On Sun, 10 Jan 2010 11:06:45 +0000, Flash Gordon wrote:

>> Notably, the standard states that reading from a "volatile" variable is a
>> sequence point, while reading from non-volatile variables isn't.

>
> C&V? I don't think reading from a volatile is a sequence point.


Ugh; sorry. Reading from a volatile is a *side-effect*, which must not
occur before the preceding sequence point and must have occurred by the
following sequence point. 5.1.2.3 p2 and p6.

>> And even if the compiler provides the "assumed" semantics for "volatile"
>> (i.e. it emits object code in which read/write of volatile variables
>> occurs in the "expected" order), that doesn't guarantee that the processor
>> itself won't re-order the accesses.

>
> However, it does have to document what it means by accessing a volatile,
> and it should be possible to identify from this whether it prevents the
> processor from reordering further down, whether it bypasses the cache etc.


Easier said than done. The object code produced by a compiler may
subsequently be run on a wide range of CPUs, including those not invented
yet. The latest x86 chips will still run code which was generated for a
386.



All times are GMT. The time now is 01:40 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.