Mike Stump wrote:
On May 4, 2005, at 12:47 PM, Chris Friesen wrote:
One problem with using volatile is that it can destroy performance.
Gosh, I was going to elaborate and give the more complete answer, but
decided against it, I was wrong.
Heh...sorry. I've been trying to figure out who's respo
On May 4, 2005, at 12:47 PM, Chris Friesen wrote:
One problem with using volatile is that it can destroy performance.
Gosh, I was going to elaborate and give the more complete answer, but
decided against it, I was wrong.
only need to really read it in from memory the first time after I
take a
Diego Novillo wrote:
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:
In multiple messages to comp.programming.threads he has stated that
volatile is not necessary between threads if you use the posix locking
functions, and in fact that one of the main purposes of the posix locks
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:
> In multiple messages to comp.programming.threads he has stated that
> volatile is not necessary between threads if you use the posix locking
> functions, and in fact that one of the main purposes of the posix locks
> is to ensure
Diego Novillo wrote:
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:
Also, what about threads and pthread locking? Do I need to use volatile
there? If not, then what about using pthread locking between processes?
Things will only break for you when GCC pulls in function bodies
a
Chris Friesen wrote:
Mike Stump wrote:
It is safer to. People might compile your whole app at once for
better optimization, and the compiler might be just smart enough to
optimize it away.
One problem with using volatile is that it can destroy performance. I
only need to really read it in
On Wed, May 04, 2005 at 04:15:41PM -0400, Diego Novillo wrote:
> Same reply I gave you before. As long as the address of your
> shared memory is outside of the function and the pointer is
> itself a global variable or gets its value from the heap, then
> calls to functions that cannot be inlined
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:
> Also, what about threads and pthread locking? Do I need to use volatile
> there? If not, then what about using pthread locking between processes?
>
Same reply I gave you before. As long as the address of your
shared memory is ou
Mike Stump wrote:
On May 4, 2005, at 10:59 AM, Chris Friesen wrote:
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile?
It is safer to. People might compile your whole app
On May 4, 2005, at 10:59 AM, Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile?
It is
Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the
memory using standard locking (fcntl(), for instance), do I need to
specify that the memory is volatile? Or is the fact that I'm using
fcnt
On Wed, May 04, 2005 at 11:59:49AM -0600, Chris Friesen wrote:
> Without the locks, the compiler is free to only load *b once (and in
> fact gcc does so). Is the addition of the locks sufficient to force *b
> to be re-read each time, or do I need to declare it as
>
As long as you keep 'b' poin
12 matches
Mail list logo
