Wait until x==true

Hello,
this problem is more exotic than you think. i'm using 2 threads to draw pixels on the screen like this:

Code:

---

// draw upper half here
ThreadPool.QueueUserWorkItem(delegate
                {
// draw pixels here
}, null);

// draw lower half here
ThreadPool.QueueUserWorkItem(delegate
                {
// draw pixels here
}, null);

---

and after that piece of code i need to pause the main thread UNTIL the both threads above have finished. of course the simplest thing would be to just set two variables and do this:

Code:

---

while(!thread1_finished || !thread2_finished) Thread.Sleep(1);

---

but that is bad, because the operations above take far less then 1 millisecond. so how do i run these two operations simultaneously and wait for both to finish?

any help appreciated. thanks.

This article might contain info you are interested in (mainly the WaitHandle part)
C# Tutorial - Using The ThreadPool | Switch on the Code

Why make it sleep? If it takes less than 1ms just make it wait.
The most optimized way is probably using a signal of some sort. For example you can use a semaphore. The main threads waits until the semaphore is released. Well, until its inner count is zero in other words, where it will start at 2 and decrease each time one operation is done.

Sleep is NEVER the best solution. When dealing with threads try always to find a logical solution independent of timing. The Sleep() is not a good practice and not guaranteed to work. Except if you have no other solution or you don't want to lose to much time to find one.

Do you have to use the threadpool? What about something like this?

Code:

---

        static void Main(string[] args)
        {
            Thread thread1 = new Thread(DrawTopPixels);
            Thread thread2 = new Thread(DrawBottomPixels);

            thread1.Start();
            thread2.Start();

            thread1.Join();
            thread2.Join();

            Console.WriteLine("Both threads have terminated.");
        }

        private static void DrawTopPixels(object obj)
        {
            // Code to draw pixels
        }

        private static void DrawBottomPixels(object obj)
        {
            // Code to draw pixels
        }
    }

---

Code:

---

            ManualResetEvent[] resetEvents = new ManualResetEvent[2];
            resetEvents[0] = new ManualResetEvent(false);
            resetEvents[1] = new ManualResetEvent(false);
            ThreadPool.QueueUserWorkItem(delegate
            {
                //draw
                resetEvents[0].Set();
            }, null);
            ThreadPool.QueueUserWorkItem(delegate
            {
                //draw
                resetEvents[1].Set();
            }, null);
            WaitHandle.WaitAll(resetEvents);

---

this is what i came up with so far and it's actually slower than using just a single thread.

Quote:

---

Originally Posted by Devils Child

this is what i came up with so far and it's actually slower than using just a single thread.

---

Okay...? And what about the suggestion that I gave? Did you try it? Did you answer the question I asked?

Are you saying you're fine with your solution even though it's slower or that you're giving up or what?

Alternately, if both methods are so fast and the main thread must wait for them anyway, why not use blocking calls?

Quote:

---

Originally Posted by Devils Child

this is what i came up with so far and it's actually slower than using just a single thread.

---

It looks like you're trying to do a multithreaded rendering loop, and you're now seeing why games don't do it -- the thread synchronization makes it slower to use multithreading than single threading.

For a very quick operation, threading is just not worth it because of the time lost to synchronizing the threads and the overhead (thread pools reduce overhead but don't eliminate it), and trying to split a single viewport's rendering loop across multiple threads without trying to synchronize them would cause a lot of artifacts as different parts of the screen are drawn at different times.

@itsme86: i did try your method and it is much slower than thread pools because we would need to create new threads for that. don't get so angry about that. and no, i'm not giving up.

@pianorain i'll try that when i'm home

@Cat: i guess you're right. synchronization takes more time then time i would save.

i think i need to think of other ways. thanks guys.