problem with Threading.Monitor

  • Thread starter Thread starter ste
  • Start date Start date
S

ste

this code not work: it is no possible Exit from Monitor
Why ?

thank
ste

////////

using System;
using System.Collections;
using System.Threading;

namespace consoleProtection
{
class Class1
{
ArrayList _obj = new ArrayList();

[STAThread]
static void Main(string[] args)
{
Class1 newClass1 = new Class1();
newClass1.go();
Sleep(15000);
}

public void go()
{
Thread _th1 = new Thread(new ThreadStart(this.enter));
_th1.Start();
Thread.Sleep(100);
Thread _th2 = new Thread(new ThreadStart(this.exit));
_th2.Start();
Thread.Sleep(100);
Thread _th3 = new Thread(new ThreadStart(this.enter));
_th3.Start();
}

void enter()
{
Console.WriteLine("try to enter");
Monitor.Enter(_obj);
Console.WriteLine("enter");
}

void exit()
{
Monitor.Exit(_obj);
Console.WriteLine("exit");
}
}
}
 
ste said:
this code not work: it is no possible Exit from Monitor
Why ?
Click to expand...

Let's recap:

You are spawing another thread, which enters the arraylist monitor, and then
dies.
Then another thread that exits the monitor (which it never entered), and
then dies.
Then another thread that tries to enter the monitor, and if sucessful, will
die.

I don't really know what happens when you let a thread die when it has an
object locked. It should never come up.

You don't call the threading lock mechanisms using background threads. What
are you trying to acomplish?

David
 
The calls to Enter and Exit must occur on the same thread. When you
call this.enter on the first thread, it holds a lock on that object
indefinitely (I believe, I don't know if the lock is released when the
thread dies, I could be wrong). When you try and exit on the second thread,
it won't work because you never entered into it on that thread.

Hope this helps.
 
ste said:
this code not work: it is no possible Exit from Monitor
Why ?
Click to expand...

As was pointed out, what you're explicitly trying to do doesn't work.

It's not clear to me if you're just trying to understand how Monitor works
or if you really need to use a mechanism that supports this, but if you do
need it, use a Mutex instead:

using System;
using System.Collections;
using System.Threading;

namespace consoleProtection
{
class Class1
{
static Mutex mtx = new Mutex();
ArrayList _obj = new ArrayList();

[STAThread]
static void Main(string[] args)
{
Class1 newClass1 = new Class1();
newClass1.go();
Thread.Sleep(15000);
}

public void go()
{
Thread _th1 = new Thread(new ThreadStart(this.enter));
_th1.Start();
Thread.Sleep(100);
Thread _th2 = new Thread(new ThreadStart(this.exit));
_th2.Start();
Thread.Sleep(100);
Thread _th3 = new Thread(new ThreadStart(this.enter));
_th3.Start();
}

void enter()
{
Console.WriteLine("try to enter");
// if someone already has locked this, it will block
mtx.WaitOne();
Console.WriteLine("enter");
}

void exit()
{
// works cross threads
mtx.ReleaseMutex();
Console.WriteLine("exit");
}
}
}


--
Reginald Blue
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my
telephone."
- Bjarne Stroustrup (originator of C++) [quoted at the 2003
International Conference on Intelligent User Interfaces]
 
first: thank for the answer ti you and to the other

second: my problem is a little more complex and i have post a "simple
version" to show the core of the question: you say me that it's no correct
that a thread die without release the monitor. But this is in the MSDN
documentation ?

In my program a thread lock a resource and another thread free. It's correct
to use a Mutex ?

thank
ste
 
The thread that acquires a mutex must be the thread that releases it. If the
thread that originally acquired the mutex terminates normally while holding
ownership the mutex is released, the state is set to signalled, and the next
waiting thread is signalled. If the thread that owns the mutex never
releases it and does not terminate then no other thread will be able to
acquire it.

This is all clearly documented. If this behavior is not suitable then you
will need to invent your own mechanism.

Mutexes are suitable when synchronizing between managed and unmanaged code,
or between processes. Monitors are typically recommended when synchronizing
threads within the same managed process.
 
Back
Top