When you run with -X:MTA, is the object now being finalized on a
thread other than thread #2?
On Thu, Nov 6, 2008 at 7:01 AM, William Reade
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no
longer reproduce the problem. However, this bothers me a bit: I'm
not competent to follow all the consequences here, but this
situation seems to imply that Ironclad won't be usable safely from
any STA thread. Is this an intended restriction or a bug?
Incidentally, tracking down the call stacks proved to be hard
work: the timing changed enough that I only got a single failure
over dozens of runs, and it turned out I'd got the logging wrong,
so I didn't find out anything useful :(.
Dino Viehland wrote:
I would suggest getting a snap shot of the call stacks when
this is happening if that's possible. I can't pin anything
down but I wonder if you could have an STA object or something
that otherwise requires message pumping. That message pumping
could happen while you're doing a Monitor.Enter call. If that
was happening maybe there is some subtle CLR bug or a surprise
feature? It is surprising that Monitor.Enter can go
re-entrant but it can...
So it'd be interesting to get thread snapshots and see if
EnsureGIL (443) 2
EnsureGIL (443) 1 <- omg, wtf, bbq, etc.
Could be happening because Thread 1 experiences contention,
blocks and pumps messages, causing the finalizer thread (2) to
run, the lock is acquired and ... ?
Only other thing I could think of is does it repro on other
machines? Maybe it's a hardware bug as unlikely as that seems?
-----Original Message-----
From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On Behalf Of
William Reade
Sent: Wednesday, November 05, 2008 10:01 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone
here may be able to help
The log starts in the middle (after many lock/unlocks, some
from each
thread); I'm running on x86; and I have no additional AppDomains.
I don't think it would be safe for me to entirely avoid
locking during
finalization, but I could probably cut it down to a quick
lock, on a
separate object, to enqueue pointers for cleanup and
deallocation on the
main thread. However, I'm reluctant to do that until I'm sure
that the
problem is specifically related to GC, otherwise it'll just
come back as
soon as anyone tries any serious multithreading :).
Curt Hagenlocher wrote:
Locking during finalization is often considered to be a
bad idea. In
particular, locking without a timeout introduces the
possibility that
you will hang the finalization thread, preventing further
objects from
being finalized. But clearly, that's not what's happening
here.
Other questions that probably don't matter but might be
interesting to
know:
Can we assume that the finalization thread isn't the first
place where
this lock is required? That your log starts somewhere in
the middle?
Is this under x86 or x64 or both?
Are you creating any additional AppDomains in the process?
On Wed, Nov 5, 2008 at 10:15 AM, William Reade
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
Hi Curt
I am indeed; that's how I know thread 2 is the GC
thread. Is
locking during GC forbidden?
William
Curt Hagenlocher wrote:
...or, for that matter, any __del__ methods from
within Python
-- which ultimately are handled by finalization.
On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>>
wrote:
So, the obvious question for me is whether or
not you're
using any
finalizers.
On Wed, Nov 5, 2008 at 5:57 AM, William Reade
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>>
wrote:
Hi all
While running the numpy tests, I've come
across a situation
which, to the best of my knowledge, is simply
impossible. I'm
hoping that one of the local .NET gurus will
be able to
tell
me what I'm missing, or point me somewhere I
can get
more insight.
The 4 methods involved are as follows:
-----------------------
public int GetThreadId()
{
return
Thread.CurrentThread.ManagedThreadId;
}
public void WriteFlush(string info)
{
Console.WriteLine(info);
Console.Out.Flush();
}
public void EnsureGIL()
{
Monitor.Enter(this.dispatcherLock);
this.WriteFlush(String.Format(
"EnsureGIL ({1}) {0}",
this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
}
public void ReleaseGIL()
{
this.WriteFlush(String.Format(
"ReleaseGIL ({1}) {0}\n",
this.GetThreadId(),
Builtin.id(this.dispatcherLock)));
Monitor.Exit(this.dispatcherLock);
}
-----------------------
...and they can, and do, occasionally
produce output as
follows:
-----------------------
EnsureGIL (443) 2
EnsureGIL (443) 1 <- omg, wtf, bbq, etc.
ReleaseGIL (443) 2
EnsureGIL (443) 2
ReleaseGIL (443) 1
ReleaseGIL (443) 2
-----------------------
When this happens, the process continues
happily for a
short
time and then falls over in a later call to
ReleaseGIL
(after
successfully calling it several times). The
error is "
Object
synchronization method was called from an
unsynchronized block
of code", which I understand to mean "you
can't release
this
lock because you don't hold it".
It doesn't happen very often, but I can usually
reproduce it
by running
test_multiarray.TestFromToFile.test_malformed a few
hundred times. It may be relevant to note
that thread 2
is the
GC thread, and thread 1 is the main thread.
I have
considered
the following possibilities:
(1) That I'm locking on the wrong object. I
believe
that isn't
the case, because it's constructed only
once, as a "new
Object()" (ie, a reference type), and is
only subsequently
used for locking; and, because it keeps the
same ipy id
throughout.
(2) That Monitor.Enter occasionally allows
two different
threads to acquire the same lock. I consider
this extremely
unlikely, because... well, how many
multithreaded .NET apps
already exist? If Monitor really were
broken, I think we'd
probably know about it by now.
(3) That calling Flush() on a SyncTextWriter
(the type of
Console.Out) doesn't actually do anything,
and the
output is
somehow wrongly ordered (although I can't
imagine how this
could actually be: if the locking is really
working,
then my
console writes are strictly sequential). I
don't have
access
to the code, so I have no idea how it's
implemented,
but even
if this is the case it doesn't help much
with the
fundamental
problem (the synchronisation error which
follows).
Apart from the above, I'm out of ideas. Can
anyone suggest
what I've missed?
William
_______________________________________________
Users mailing list
Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>
<mailto:Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>>
<mailto:Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>
<mailto:Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>>>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>
<mailto:Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>
<mailto:Users@lists.ironpython.com
<mailto:Users@lists.ironpython.com>>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com <mailto:Users@lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
