Pete French <[EMAIL PROTECTED]> writes:
>> Thread B on Processor B sees isCreated = 1, but still has a stale
>> value (nil) for 'theInstance' in its L1/L2 memory cache
>> and returns the nil.
>
> I can't imagine that this would ever happen - if processors in an SMP
> system
> Thread B on Processor B sees isCreated = 1, but still has a stale
> value (nil) for 'theInstance' in its L1/L2 memory cache
> and returns the nil.
I can't imagine that this would ever happen - if processors in an SMP
system had independent caches such that they saw differ
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> - (id) sharedInstance
> {
>static volatile uint8_tisCreated = 0; // single byte
>declared volatile so we read from memory rather than a register
>static volatile id theInstance = nil;
>
>if (isCreated == 0)
> {
>
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> - (id) sharedInstance
> {
>static volatile uint8_tisCreated = 0; // single byte
>declared volatile so we read from memory rather than a register
>static volatile id theInstance = nil;
>
>if (isCreated == 0)
> {
>
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> I've committed a change which moves the call to -gcFinalise into -
> dealloc and replaces the implementation of -release with:
>
> {
>M_LOCK(connection_table_gate);
>if (NSDecrementExtraRefCountWasZero(self))
> {
>NSHashRe
On 8 Sep 2006, at 08:57, David Ayers wrote:
Richard Frith-Macdonald schrieb:
Can you see any problems with this?
I don't think -retain needs to lock the gate, and as long as we are
only locking in the -release method as above, I think we can avoid
using a recursive lock (as I don't think we c
Richard Frith-Macdonald schrieb:
> Can you see any problems with this?
> I don't think -retain needs to lock the gate, and as long as we are
> only locking in the -release method as above, I think we can avoid
> using a recursive lock (as I don't think we call -release inside any
> region where
On 7 Sep 2006, at 16:55, Wim Oudshoorn wrote:
Can you see any problems with this?
I don't think -retain needs to lock the gate, and as long as we are
only locking in the -release method as above, I think we can avoid
using a recursive lock (as I don't think we call -release inside any
region whe
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> On 7 Sep 2006, at 12:23, Richard Frith-Macdonald wrote:
> I've committed a change which moves the call to -gcFinalise into -
> dealloc and replaces the implementation of -release with:
>
> {
>M_LOCK(connection_table_gate);
>if (NSDecr
On 7 Sep 2006, at 12:23, Richard Frith-Macdonald wrote:
So ... I think we have to assume that the interpretation of this
is ...
If a release causes the extra reference count to drop to zero then
we assume that no other thread can access the object (if another
thread could access it, it sh
On 7 Sep 2006, at 11:26, Richard Frith-Macdonald wrote:
On 7 Sep 2006, at 10:56, Wim Oudshoorn wrote:
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
2 - the connection_table_gate is a non-recursive lock.
Changed to be recursive.
3 - the connection_table_gate should NOT change to a
On 7 Sep 2006, at 10:56, Wim Oudshoorn wrote:
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
2 - the connection_table_gate is a non-recursive lock.
Changed to be recursive.
3 - the connection_table_gate should NOT change to a recursive lock
because it guards a hash table.
That'
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
>> 2 - the connection_table_gate is a non-recursive lock.
>
> Changed to be recursive.
>
>> 3 - the connection_table_gate should NOT change to a recursive lock
>> because it guards a hash table.
>
> That's not a problem because the table does
On 6 Sep 2006, at 18:40, Wim Oudshoorn wrote:
I suggested usiing the refGate, not the connection table lock,
bug using the refGate is horribly wrong and I was quite stupid to
suggest that.
Glad you didn't follow my suggestion.
But using the connnection table lock, might not be wise, because
Richard Frith-Macdonald <[EMAIL PROTECTED]> writes:
> On 6 Sep 2006, at 14:31, Wim Oudshoorn wrote:
>
>> So it seems that an NSConnection is deallocated but still exists in
>> the connection_table.
>>
>> Looking at the NSConnection code, a connection is added to this
>> table in the
>> -init... m
On 6 Sep 2006, at 14:31, Wim Oudshoorn wrote:
So it seems that an NSConnection is deallocated but still exists in
the connection_table.
Looking at the NSConnection code, a connection is added to this
table in the
-init... method, and removed in the -invalidate method.
To me this look
On a 64 bit multiprocessor machine, running Redhat,
our program sometimes crashes, but unfortunately not
easily reproducable.
I was lucky enough to capture one crash while
running under valgrind and the valgrind output
is interesting:
==15122==
==15122== Invalid read of size 8
==15122==at 0x
17 matches
Mail list logo
