Method calls in .NET multithreading

[Ioannis Vranos]

In .NET multithreading we have to assign a thread to a method of a
separate object each time (and not two methods of the same object)?
In other words, why does this hung?
#using <mscorlib.dll >

using namespace System;
using namespace System::Threadi ng;
class SomeException
{};
__gc class SomeClass
{
int index;

//...

public:

// ...
void DoSomething()
{
Monitor::Enter( this);

throw SomeException() ;

// Modify index

Monitor::Exit(t his);
}

void DoSomethingElse ()
{
Monitor::Enter( this);

// Modify index

Monitor::Exit(t his);
}

// ...
};
int main() try
{
SomeClass *ps= __gc new SomeClass;
Thread *pthread1= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omething) );

Thread *pthread2= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omethingElse) );
//Start execution of ps->DoSomething( )
pthread1->Start();

//Start execution of ps->DoSomethingEls e()
pthread2->Start();
}

catch(SomeExcep tion)
{
Console::WriteL ine("SomeExcept ion caught in main thread!\n");
}

[Ioannis Vranos]

Ioannis Vranos wrote:

In .NET multithreading we have to assign a thread to a method of a
separate object each time (and not two methods of the same object)?

In other words, why does this hang?
I had pasted wrong code. Here is the correct one:
#using <mscorlib.dll >

using namespace System;
using namespace System::Threadi ng;

class SomeException
{};

__gc class SomeClass
{
int index;

//...

public:

// ...
void DoSomething() try
{
Monitor::Enter( this);

throw SomeException() ;

// Modify index

Monitor::Exit(t his);
}

==> Handle inside the specific thread locally
catch(SomeExcep tion)
{
// ...
}

void DoSomethingElse ()
{
Monitor::Enter( this);

// Modify index

Monitor::Exit(t his);
}

// ...
};
int main() try
{
SomeClass *ps= __gc new SomeClass;
Thread *pthread1= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omething) );

Thread *pthread2= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omethingElse) );
//Start execution of ps->DoSomething( )
pthread1->Start();

//Start execution of ps->DoSomethingEls e()
pthread2->Start();
}

catch(Exception *pe)
{
Console::WriteL ine("{0}", pe->Message);
}

[Doug Harrison [MVP]]

On Fri, 25 Mar 2005 06:00:34 +0200, Ioannis Vranos wrote:

Ioannis Vranos wrote:

In .NET multithreading we have to assign a thread to a method of a
separate object each time (and not two methods of the same object)?

In other words, why does this hang?
I had pasted wrong code. Here is the correct one:
#using <mscorlib.dll >

using namespace System;
using namespace System::Threadi ng;

class SomeException
{};

__gc class SomeClass
{
int index;

//...

public:

// ...
void DoSomething() try
{
Monitor::Enter( this);

throw SomeException() ;

// Modify index

Monitor::Exit(t his);
}

==> Handle inside the specific thread locally
catch(SomeExcep tion)
{
// ...
}

void DoSomethingElse ()
{
Monitor::Enter( this);

// Modify index

Monitor::Exit(t his);
}

// ...
};
int main() try
{
SomeClass *ps= __gc new SomeClass;
Thread *pthread1= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omething) );

Thread *pthread2= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoS omethingElse) );
//Start execution of ps->DoSomething( )
pthread1->Start();

//Start execution of ps->DoSomethingEls e()
pthread2->Start();
}

catch(Exception *pe)
{
Console::WriteL ine("{0}", pe->Message);
}

I can't get this to hang.

You're starting two threads to run functions on the object ps, which is
fine in and of itself. However, the function DoSomething locks ps, throws
an exception, and apparently fails to unlock ps. Provided the thread goes
on to exit, I believe this will abandon the sync object associated with ps,
making it available to DoSomethingElse . If for some reason DoSomething
doesn't exit, then there's the potential for DoSomethingElse to wait
forever, and your program will hang. The solution to that is to unlock
"this" inside your catch block. (Of course, this all assumes the threads
execute in the order they're created.)

--
Doug Harrison
Microsoft MVP - Visual C++

[Ioannis Vranos]

Doug Harrison [MVP] wrote:

I can't get this to hang.

Strangely enough, it does not hang always. Run it sometimes and you will
see it hanging. I can not understand why it does not hang all the time
though (since Monitor::Exit() is not called in the catch block).
You're starting two threads to run functions on the object ps, which is
fine in and of itself. However, the function DoSomething locks ps, throws
an exception, and apparently fails to unlock ps. Provided the thread goes
on to exit, I believe this will abandon the sync object associated with ps,
making it available to DoSomethingElse . If for some reason DoSomething
doesn't exit, then there's the potential for DoSomethingElse to wait
forever, and your program will hang. The solution to that is to unlock
"this" inside your catch block. (Of course, this all assumes the threads
execute in the order they're created.)

Yes, Monitor::Exit(t his); inside the catch block makes the program to
never hang. However why it hangs sometimes and sometimes it doesn't,
without this?

[Doug Harrison [MVP]]

On Fri, 25 Mar 2005 08:20:05 +0200, Ioannis Vranos wrote:

Strangely enough, it does not hang always. Run it sometimes and you will
see it hanging. I can not understand why it does not hang all the time
though (since Monitor::Exit() is not called in the catch block).
FWIW. I ran it 20 times in a row, and it never hung. Aren't MT problems
fun?
Yes, Monitor::Exit(t his); inside the catch block makes the program to
never hang. However why it hangs sometimes and sometimes it doesn't,
without this?

It turns out I was wrong. Unlike a mutex, the SyncBlock associated with an
object is not abandoned when a thread exits while holding it. However, I
was on the right track when I alluded to order issues. Provided thread 1
runs before thread 2, locks the object, and exits, thread 2 will block
forever on its Monitor.Enter call. To make it do so (almost)
deterministical ly, insert the following at the start of DoSomethingElse :

Thread::Sleep(1 000);

This should give thread 1 enough time to do its thing and mess up thread 2.

--
Doug Harrison
Microsoft MVP - Visual C++

[Ioannis Vranos]

Doug Harrison [MVP] wrote:

Strangely enough, it does not hang always. Run it sometimes and you will
see it hanging. I can not understand why it does not hang all the time
though (since Monitor::Exit() is not called in the catch block).

FWIW. I ran it 20 times in a row, and it never hung. Aren't MT problems
fun?

I compiled it from command line, with cl /clr /EHsc temp.cpp and no
other switch. /EHsc is important.

Yes, Monitor::Exit(t his); inside the catch block makes the program to
never hang. However why it hangs sometimes and sometimes it doesn't,
without this?

It turns out I was wrong. Unlike a mutex, the SyncBlock associated with an
object is not abandoned when a thread exits while holding it. However, I
was on the right track when I alluded to order issues. Provided thread 1
runs before thread 2, locks the object, and exits, thread 2 will block
forever on its Monitor.Enter call. To make it do so (almost)
deterministical ly, insert the following at the start of DoSomethingElse :

Thread::Sleep(1 000);

This should give thread 1 enough time to do its thing and mess up thread 2.

Does it hang to you with this way? :-)

[Jochen Kalmbach]

Hi Ioannis,

void DoSomething()
{
Monitor::Enter( this);

throw SomeException() ;

// Modify index

Monitor::Exit(t his);
}

The abouve code will always forget to call the "Exit" !
Normally you should *always* do:

Monitor::Enter( this);
__try
{
}
__finally
{
Monitor::Exit(t his);
}
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Doug Harrison [MVP]]

On Fri, 25 Mar 2005 10:49:31 +0200, Ioannis Vranos wrote:

Doug Harrison [MVP] wrote:

To make it do so (almost)
deterministical ly, insert the following at the start of DoSomethingElse :

Thread::Sleep(1 000);

This should give thread 1 enough time to do its thing and mess up thread 2.

Does it hang to you with this way? :-)

Yes. I said "almost" deterministical ly because it's using Sleep to fake out
the scheduler, a practice that isn't guaranteed to work but does well
enough to demonstrate the problem.

Aside: It's interesting to note that by using the Thread class, your
example illustrated the use of foreground threads. Had you used background
threads, or if you were to set the IsBackground property on the threads,
your program would have terminated right away, because extant background
threads don't keep a program alive once the primary thread has exited. Only
foreground threads do that. In general, you should join with your secondary
threads before exiting your primary thread.

--
Doug Harrison
Microsoft MVP - Visual C++

[Ioannis Vranos]

Doug Harrison [MVP] wrote:

Yes. I said "almost" deterministical ly because it's using Sleep to fake out
the scheduler, a practice that isn't guaranteed to work but does well
enough to demonstrate the problem.

Aside: It's interesting to note that by using the Thread class, your
example illustrated the use of foreground threads. Had you used background
threads, or if you were to set the IsBackground property on the threads,

.... the only way that I know for creating .NET background threads. Is
there another?

your program would have terminated right away, because extant background
threads don't keep a program alive once the primary thread has exited.

Yes indeed.
Only
foreground threads do that. In general, you should join with your secondary
threads before exiting your primary thread.

You mean to join the primary thread and secondary threads all together?
However this doesn't sound much multithreading. :-)
Something else based on this, is it better to join dependent threads -
whenever possible- instead of using locks? What would this mean for
performance in multi-cpu/core environments? Is this a way to avoid the
thread lock mess, while sacrificing almost no speed?

[Doug Harrison [MVP]]

On Sat, 26 Mar 2005 04:34:26 +0200, Ioannis Vranos wrote:

... the only way that I know for creating .NET background threads. Is
there another?
Thread pool and by extension asynchronous delegates. In addition, unmanaged
threads that call into managed code are marked as background threads.
You mean to join the primary thread and secondary threads all together?
However this doesn't sound much multithreading. :-)
But if your program is shutting down, it's usually undesirable to allow
your secondary threads to continue to run as the larger environment in
which they're executiing is going away. To conduct an orderly shutdown,
your primary thread has to ask all your secondary threads to exit and join
with them first.
Something else based on this, is it better to join dependent threads -
whenever possible- instead of using locks?
Not sure what you mean. By "join" I mean wait for the thread to exit.
What would this mean for
performance in multi-cpu/core environments? Is this a way to avoid the
thread lock mess, while sacrificing almost no speed?

Google on "lock-free programming". It's a hot topic these days.

--
Doug Harrison
Microsoft MVP - Visual C++