> 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 considere
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 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
On Thu, 10 Mar 2011 12:18:22 +0100
Sturla Molden 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 order of exe
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 an
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 t
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
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
h
On Wed, Mar 9, 2011 at 8:42 PM, "Martin v. Löwis" 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" would only be
h
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 La
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 vola
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 obse
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
Atomic operations (InterlockedCompareExchange, et al.) are used on the
field 'owned' in NRMUTEX. These methods require the memory to be aligned
on 32-byte boundaries. They also require the volatile qualifer. Three
small changes are therefore needed (see below).
Regards,
Sturla Molden
t
14 matches
Mail list logo
