I wnat to change my fake threading trick into a real threading system.. RRS feed

  • Question

  • Hello again.
    I am still busy with my hobby project :)
    Excuse me for the fantasy explanaiton that i will give of my thing that i want to know.
    Just remember that i can work 10x better using my metasymbolic explanations.

    What i am trying to do is to create seperate threads in my vj program (something like ,
    I will call my vjprograms 'main' , my waterpool..
    My magic waterpool is making new stuff :
    -a direct3d form
    -a user console form
    -a class that is working with networking (with a socket recieve on a seperate thread)
    -a class that is parsing a avi file as io-filestream (to extract basic meta-info) , and after that extract a video frame using directshow.

    I call these my frogs (altough some of them are invisble , and some are missing limbs , they can all make sound)
    They all communicate using my custom message object (time,catagory,command,val a,val b,val c,comments)
    When a event (with my messageobject) comes from one of my frogs -> add the message to my custom message que.

    My waterpool has a mainloop:
    While CodeRed = false 
        -do my messagepump()
        -application.dovents per xx miliseconds
        -do direct3d frame updates per xx miliseconds
        -do direct3d sceneobject updates per xx miliseconds
        -do network still alive checks per xx seconds

    Sub Do my messagepump:
    1.oldest first
    2.per catagory (by select case)
    3.per command (by select case)
    Then the command starts a function on a frog , or could change some stuff "with the properties in the waterpool.

    All in all this stuf is mostly single threaded.
    The biggest problem is , that if one frog is being too busy ,all the frogs stop functioning.
    I want to change it into multi threaded, that if one frog is too busy , the others just keep on going..

    Can you give me some clues how to do:
    -start a form in a seperate thread
    -grab and send my custom messages to a form/class  in a thread
    Saturday, June 14, 2008 10:44 AM

All replies

  • I'll try to focus on the last two lines of your post.  Create a form on another thread by calling its Show() or ShowDialog() method on that thread.  In the case of Show(), you must keep the form alive by pumping a message loop with Application.Run().  Deliver messages to a form by using its Invoke() or BeginInvoke() method.

    In general, running forms on separate threads is a bad idea.  Do the hard work on background threads, leave the main UI thread unoccupied so it can keep the UI alive.  The BackgroundWorker component can be helpful.

    Hans Passant.
    Saturday, June 14, 2008 6:28 PM
  • thnx , for the fast reply.
    i have looked into that too , but still havent figured out what i would need program , to send and receive events to the threads (if they are forms)

    my biggest problem is that : the userinterface and the 3d window are battling for cpu cycles !

    Now i am working without threading in my UI..
    My 3d window needs 70% cpu (leaving 30% for my UI),but UI form takes 50% (guessing)..

    When i remove application.dovents from my mainloop , my ui stalls.
    Maybe my mainloop (that cycles between 3d-form and UI) becomes too fast , i dont know.

    What i want is to let the UI update for like 5 fps . Leaving all the power towards the 3d interface.

    I know my questions are rather vague , but i am learning... Thank in advance..

    I will try to run my 3d window first as a background thread , lets see what happens..

    As a lost resort i could split my program in two, one 3d window with a network class , and the other will be a user interface with a network class...

    Sunday, June 15, 2008 11:50 PM
  • Hi Jarno!

    I think you've got your "threading picture" a little bit wrong. You need to understand the difference between the UI thread (main thread) and the background thread (sometimes called worker thread). The UI thread handles all that has to do with the UI, such as handling user input events (keypress, mouse clicks) and updating the interface (such as setting an image, or putting some text in a label).

    If I understand you correctly you have today only one thread that is doing all of your work and that is making your UI become non-responsive from time to time. This is an ideally situation to introduce worker threads, however(!), you need to stop thinking of one thread taking care of the "direct3d" form and another the "console" form etc. Instead the UI thread should handle all your graphical forms. Let the worker threads handle the heavy work underneath each form.

    nobugz mentioned the BackGroundWorker component as helpful, however for long time running operations or even when the worker thread lives through out the whole application lifetime you might concider implementing your own custom threads to gain more control.

    This whole threading thing is sometimes a bit hard to grasp, and I do recommend you to study the subject a bit before jumping into coding.
    Good luck!


    Sunday, June 22, 2008 10:26 AM