On Thursday 10 March 2011, Sturla Molden wrote:
As for InterlockedCompareExchange et al., MSDN says this: The
parameters for this function must be aligned on a 32-bit boundary;
bit != byte
Uli
**
Domino
On Wed, Mar 9, 2011 at 8:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
As for the volatile marker - I believe the code is also
correct without it, since the owned field is only accessed
through initialization and Interlocked operations.
Furthermore, if the code weren't correct, volatile
On 3/10/2011 3:07 AM, Paul Du Bois wrote:
volatile considered harmful
http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
--
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
Python-Dev mailing list
Python-Dev@python.org
This behavior (which volatile aggravates) unfortunately makes it
even tougher to find race conditions. In my experience,
volatile should be avoided. I'd even bet money that some grumpy
person has written a volatile considered harmful essay.
I guess all this advice doesn't really apply to
Den 10.03.2011 11:06, skrev Scott Dial:
http://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
The important part here (forgive me for being a pedant) is that register
allocation of the (1) 'owned' field is actually unwanted, and (2)
Microsoft specify 'volatile' in calls
Martin v. Löwis:
I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it proper usage of the API to declare the storage
volatile.
The 'volatile' here is a modifier on the parameter and
On Thu, 10 Mar 2011 12:18:22 +0100
Sturla Molden stu...@molden.no wrote:
Obvious usecases for volatile are:
- Implementation of a spinlock, where register allocation is detrimental.
- A buffer that is filled from the outside with some DMA mechanism.
- Real-time programs and games where
I am sorry for misreading 32 bits (4 bytes) as 32 bytes. That is
obviously very different. If Microsoft's malloc is sufficient, why does
MSDN tell us to use _aligned_malloc instead of malloc?
I don't know. Perhaps they assume that people may be using alternative
malloc implementations, or (more
Am 10.03.11 07:55, schrieb Neil Hodgson:
Martin v. Löwis:
I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it proper usage of the API to declare the storage
volatile.
The 'volatile'
I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it proper usage of the API to declare the storage
volatile. So ISTM that we should comply regardless of whether volatile
is considered
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
Mark
Den 10.03.2011 03:02, skrev Mark Hammond:
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
Ok, sorry :-)
It would also be good to know if there is an actual behaviour bug
caused by this (ie, what problems can be
Am 09.03.11 20:25, schrieb Sturla Molden:
These methods require the memory to be aligned
on 32-byte boundaries.
You misread the documentation - it's a 32-*bit*
boundary that the LONG variable must be on. The malloc()
call that is currently used trivially meets this requirement.
As for the
13 matches
Mail list logo
