multiple threads writing to WebBrowser, getting deadlocked

Zytan <zy**********@g mail.comwrote:

I have multiple threads writing to WebBrowser (using a function that
checks InvokedRequired , and if so, invokes itself on the WebBrowser
thread) and they are getting deadlocked.

They only deadlock when I use lock { } around the call to
WebBrowser.Writ e to ensure thread safety!

Does any one have experience with such a thing?

Hang on - do you mean you've already got a lock when you call Invoke?

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Zytan wrote:

I have multiple threads writing to WebBrowser (using a function that
checks InvokedRequired , and if so, invokes itself on the WebBrowser
thread) and they are getting deadlocked.

They only deadlock when I use lock { } around the call to
WebBrowser.Writ e to ensure thread safety!

Using 'lock' doesn't make sense.

WebBrowser is a WinForms control, and should only be accessed from its
UI thread. So, if you use Control.InvokeR equired, and properly use
Control.Invoke or Control.BeginIn voke to marshal your call over to the
UI control, you don't need to use 'lock', because all code that touches
the WebBrowser control is serialized on its UI thread.

Access to Control.InvokeR equired is not required to be synchronized - in
fact, it would be easy to deadlock if it and its ilk did require
synchronization . Similarly, Control.Invoke, Control.BeginIn voke etc.
don't require synchronization - check docs for Control.InvokeR equired.

-- Barry

--
http://barrkel.blogspot.com/

Zytan wrote:

I have multiple threads writing to WebBrowser (using a function that
checks InvokedRequired , and if so, invokes itself on the WebBrowser
thread) and they are getting deadlocked.

They only deadlock when I use lock { } around the call to
WebBrowser.Writ e to ensure thread safety!

Does any one have experience with such a thing?

Well if you do:

class Foo
{
//Some stuff to setup a WebBrowser control called WebBrowser

public void SomeMethod()
{
lock(WebBrowser )
{
if(InvokeRequir ed)
{
Invoke(new SomeDelegate(So meMethod));
} else {
//Do something
}
}
}
}

This will result in a deadlock when called from a thread other than the
UI thread. Instead, you should do:

class Foo
{
//Some stuff to setup a WebBrowser control called WebBrowser

public void SomeMethod()
{
if(InvokeRequir ed)
{
Invoke(new SomeDelegate(So meMethod));
} else {
lock(WebBrowser )
{
//Do something
}
}
}
}
}

If you want more than that, post some code :-)

Alun Harford

Hang on - do you mean you've already got a lock when you call Invoke?

Yes.

Could you post a short but complete program which demonstrates the
problem?

Ok, I made a small program that does nothing but start a timer that
ticks every second. It calls MyWriteLine. This calls (using
InvokeRequired + Invoke, if needed) WebBrowser.Docu ment.Write. (Well,
it makes sure the WebBrowser has a Document to write to, and if not,
navgiates to "about:blan k" first).

Then, I made a thread that I can start/stop with two buttons, this
thread does the same thing as the timer. The stop button calls
myThread.Join() ; to wait for the thread to complete.

Starting the thread is fine, they both update te WebBrowser. Stopping
the thread hangs on myThread.Join() ;

I thought this is a problem with synchronization , so I made a wrapper
to MyWriteLine, and placed a critical section lock into. Thus,
MyWriteLine is only called within a critical section. Now, the
program hangs at the lock statement when I stop the thread.

I'd post the code, but I don't have it with me at the moment. I'll
code it again, and do some more testing. I have a feeling that
replacing WebBrowser with another control solves the problem.

Zytan

WebBrowser is a WinForms control, and should only be accessed from its

UI thread. So, if you use Control.InvokeR equired, and properly use
Control.Invoke or Control.BeginIn voke to marshal your call over to the
UI control, you don't need to use 'lock', because all code that touches
the WebBrowser control is serialized on its UI thread.

Ok, I knew that Control.Invoke made the call on the same thread as
Control, but, I am unaware of what it's doing internally. I don't
know what 'marshal' actually means. So, it basically means it is
serialized on the Control's thread, meaning that all calls to
Control.Invoke are called in order, one after the other, and thus
multiple threads all calling Control.Invoke to update a single control
will be safe.

Access to Control.InvokeR equired is not required to be synchronized - in
fact, it would be easy to deadlock if it and its ilk did require
synchronization . Similarly, Control.Invoke, Control.BeginIn voke etc.
don't require synchronization - check docs for Control.InvokeR equired.

Ok, thanks, Barry

Zytan

Well if you do:

>
class Foo
{
//Some stuff to setup a WebBrowser control called WebBrowser

public void SomeMethod()
{
lock(WebBrowser )
{
if(InvokeRequir ed)
{
Invoke(new SomeDelegate(So meMethod));
} else {
//Do something
}
}
}
}

Ha ha, yes, I wasn't stupid enough to recusively attempt to enter the
same lock. The lock I have is in a wrapper around SomeMethod().

If you want more than that, post some code :-)

I will once I make my small source example again.

Zytan

Code example: Make two Buttons (btnStart, btnStop), and one
WebBroswer (webLog), and paste this into the main Form:

Thread myThread;
private volatile bool m_ThreadProcess ing = false;
private int m_count = 0;

private void ThreadFunc()
{
while (m_ThreadProces sing)
{
Thread.Sleep(40 0);
m_count++;
MyWrite(webLog, m_count + "<br>" +
Environment.New Line);
}
}

private void btnStart_Click( object sender, EventArgs e)
{
if (myThread == null)
{
myThread = new Thread(ThreadFu nc);
m_ThreadProcess ing = true;
myThread.Start( );
}
}

private void btnStop_Click(o bject sender, EventArgs e)
{
if (myThread != null)
{
m_ThreadProcess ing = false;
myThread.Join() ; // <------------- HANGS HERE!
myThread = null;
}
}

delegate void MyWrite_Delegat e(WebBrowser web, string str);
public static void MyWrite(WebBrow ser web, string str)
{
if (web.InvokeRequ ired)
{
MyWrite_Delegat e funcptr = MyWrite;
object[] args = { web, str };
web.Invoke(func ptr, args);
}
else
{
if (web.Document == null) web.Navigate("a bout:blank");
web.Document.Wr ite(str);
web.Document.Wi ndow.ScrollTo(0 , int.MaxValue); //
scroll to bottom
}
}

Note that this hangs only with this single thread accessing the
WebBrowser. Not even the main thread accesses it! (I'm preparing for
you guys to show me the obvious error I've been missing all day.)

Zytan

On Apr 3, 4:49 pm, "Zytan" <zytanlith...@g mail.comwrote:

Code example: Make two Buttons (btnStart, btnStop), and one
WebBroswer (webLog), and paste this into the main Form:

<snip>

Yes, that would hang. You're using "Invoke" from myThread - that will
block until the delegate you've passed it has been executed on the UI
thread.

Now, from the UI thread, you're calling myThread.Join - that will
block until myThread has completed.

So, how can either of them get anywhere?

Jon

Yes, that would hang. You're using "Invoke" from myThread - that will

block until the delegate you've passed it has been executed on the UI
thread.

Now, from the UI thread, you're calling myThread.Join - that will
block until myThread has completed.

Ok, it's a deadlock.

I was uncertain as what happened as a result of Invoke. Thanks to
your reply, I have a better idea. The message queue in the main
thread is processing the 'stop button clicked' message, which is
running Thread.Join, which is waiting for myThread to terminate. The
message queue is stalled (never a good idea).

myThread is upset that it doesn't own the control (as it shouldn't,
since it doesn't have a message queue to maintain it), so it tells the
GUI thread to deal with it, via Invoke. Now, my understanding is that
Invoke is *not a function pointer call* (perhaps this is why they call
them delegates, instead of function pointers?), it is a message placed
in the GUI thread. (This is why an earlier post mentioned that
Control.Invoke is serialized, meaning they are handled one at a time,
because the message queue processes one message at a time. So, if
multiple threads posted multiple messages into the queue, it still
does one at a time, and my WebBrowser doesn't need a critical
section.) But, the GUI thread has its message queue stalled.

Solution #1: Use BeginInvoke, which is a 'non blocking' call (it must
call Win32's PostMessage instead of SendMessage).

Solution #2: Don't use Thread.Join(). The examples show it, so I
used it. Often, it is unneeded.

Solution #3: Don't make the worker threads access the GUI.

Solution #4: Use BackgroundWorke r, which I presume doesn't have this
issue (I think it calls a function of yours when it is done, so you
never have to call something like BackgroundWorke r.Join, which likely
doesn't exist).

Does that all make sense?

Zytan