Threads, lock{} behaviour!

Question

4.00/5 (1 vote)

See more:

Hi all,
i am using locks to terminate 2 threads before i close my child Form.
But when i close the form, some times it closes, and some time it dosent!

here is the code:

main-thread:

C#

private void Capture_FormClosing(object sender, FormClosingEventArgs e)
{
    lock (lockThread1)
   {

       quitThread1 = true; 
   }
//wait until thread1 terminates(works fine)!
// Better Use Join instead thread1.Join();
while (Thread1.ThreadState != System.Threading.ThreadState.Stopped)
      {
         Console.WriteLine("Closing thread1...");
         //application is traped in here when closing fail
      }
}

thread 1:

C#

while(condition)
{
//Do some work...
  lock (lockThread1)
  {
      if(quitThread1) 
         return; //when using return in the thread method, this thread quit its method and                   //its state change to stopped
  }
}

i have doubt about the Lock behaviour.
Qestion: when the lock is used by thread1, mainThread wait's until the Lock is released or it skips the in Lock code?
or maybe i am doing somthing wrong in another part of the code!?

Thx in advance.

Posted 30-Oct-13 5:13am

Ziee-M

Updated 30-Oct-13 23:50pm

v4

Add a Solution

3 solutions

Solution 2

I agree with SAK. Your code does look suspicious. I don't see the need for the Lock in the Form_Closing, but then again, I know nothing about your code other than what you posted.

A Lock should wrap a "contended resource". You don't use it to control access to a thread. You use it inside threads to control access to a resource where only one thread should have access to a shared resource.

Posted 30-Oct-13 6:50am

Dave Kreskowiak

Comments

Ziee-M 30-Oct-13 13:27pm

Hi Dave, so in other word, the lock is totaly useless no? since main thread can change the variable value while thread1 only reads it?

Dave Kreskowiak 30-Oct-13 13:59pm

In the context of the code that you posted, yes, it's useless.

Solution 3

First of all it doesn't appear that you need the lock at all.
The boolean quitThread1 can be set or read atomically, and you don't appear to have a possibility of two setters attempting to set conflicting values.

If you really want to have guaranteed thread safe protection on a value, then look at the Interlocked class:
http://msdn.microsoft.com/en-us/library/system.threading.interlocked(v=vs.110).aspx[^]

Posted 30-Oct-13 7:38am

Matt T Heffron

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-10-30T05:36:00

Solution 1

When two or more threads try to get the lock on the same lock object, only one can pass, other threads are blocked to a wait state (which does not spend any CPU time until a thread is waken up, by such condition as release of the lock by other threads, abort or timeout), and the threads in the wait state are waken up, according to their positions in the queue. If the lock is done on different lock objects, such thread do not interfere each other at all. "Main thread" or not, never matters.

I answered your question, now, something extra…

Note that your code looks suspicious, at least in terms of practical programming. If you explain your ultimate goals, I'll be able to help you. In the meanwhile, please read my past answers related to thread synchronization used with System.Windows.Forms and beyond:
Problem with Treeview Scanner And MD5[^],
Control.Invoke() vs. Control.BeginInvoke()[^].

—SA

Posted 30-Oct-13 5:36am

Sergey Alexandrovich Kryukov

Comments

Ziee-M 30-Oct-13 11:45am

thx, i guess i have somthing wrong in another part of the codes. but i'am very intresetd to know why you think there is somthing suspicious in the code(contructive critique are always welcome).

Sergey Alexandrovich Kryukov 30-Oct-13 12:00pm

Anyway, your original question is answered, will you accept it formally (green "Accept" button)?

I cannot simply explain "suspicious" part before you explain what exactly you are trying to achieve.
I would like to add: I really appreciate your attitude to criticism, but I would note that in many cases, even non-constructive but reasonable criticism can be useful and also should be appreciated. On a simple example: imagine someone finds your bug, without telling you the fix. Isn't it much better than not knowing about a bug at all? At least you can start working at the resolution, be wary about about using the buggy code, etc...

—SA

Ziee-M 30-Oct-13 12:07pm

:) thx again, sorry i cant explain since this is the 6th months of work in this project, and i have more then 6000 line of code, so i dont know from where i will start explaining.

Sergey Alexandrovich Kryukov 30-Oct-13 14:20pm

Understood. Anyway, you are very welcome, as well as your further questions.
—SA