High priority thread / low priority thread

    Nov 08 2012 | 11:35 am
    I understand there are two threads in Max (when overdrive is switched on).
    Are they truly separate in as much as they can both be running at the same time? (which I'm guessing would require a multi core processor)
    Or are the messages still processed one at a time? (albeit reordered so high priority messages are executed at the right time)
    Or something completely different?

    • Nov 08 2012 | 1:16 pm
      they're two separate threads (if Overdrive is on).
      Regarding 'same-timeness', that depends on what you call 'same time'. Very strictly speaking, I guess you can't execute more instructions at the same time than the number of cores that your CPU has. However, how the CPU schedules its tasks is really machine and OS dependent, and a user doesn't really have to care about this.
      'Threads' are the abstracted concepts for tasks that the OS needs to execute in parallel, and for the user, they look as if they were running 'at the same time', independently of each other. However, this is an 'emulated same-timeness', since there are hundreds of threads running on an OS during normal operation, and you have much less cores on an average CPU than that. What the OS usually does is, that after some running time, it interrupts the currently running threads, saves their states and switches to other threads. As you may see, this behaviour is independent of the question of single- or multi-core CPUs.
      To answer your question, you can't make any assumptions about the order of execution of events that are in two separate threads. If A and B are two events in two separate threads, it might happen that A runs before B, or B runs before A, or (to make things more complicated), the OS starts running A, then stops the thread, switches to the other thread and runs B, and after that, switches back to the original thread and finishes running A...
      So, if Overdrive is ON, this will be your case. If Overdrive is OFF, you run in a single thread, so you can tell exactly the order of execution of your events. However, since in that case you're running everything on a single thread, the scheduler's events might easily get out of sync, as they have to wait for other events to execute before them.
      Hope that helps, Ádám
    • Nov 08 2012 | 1:19 pm
      says: Using multiple threads also has the advantage that on multi-processor machines, one processor could be executing low priority events, while a second processor could be executing high priority events.
    • Nov 08 2012 | 1:24 pm
      Yep, although one has to emphasize the could word in that sentence. Really, you don't need to make assumptions about which processor executes what. Since you can't make any guesses about what other tasks the OS has to take care about, it's better to let the OS itself decide the optimal way of using its resources. So, you could have the two threads on two separate processors, and you also could have them on the same. Our lives are in the OS's hands. ;-)
    • Nov 08 2012 | 1:26 pm
      Thank you Adam, that is a great help. It's enlightening to know that my operating system is running hundreds of threads, only two of which belong to Max. Helps me to put it in perspective.
    • Nov 08 2012 | 1:28 pm
      Yes jvkr, I had also read that sentence of that document.
    • Nov 08 2012 | 1:32 pm
      BTW, I think this article will help you a lot in understanding these concepts:
      and the thing that you need to realize is that the execution of the threads is not related to Max, but to the OS itself. Max only decides whether it uses one thread or two for event execution.
      HTH, Ádám
    • Nov 08 2012 | 1:44 pm
      I would just add that if your DSP is on, then you have another thread for the audio chain; and there are some more complex threading scenarios that can arise with [poly~ @parallel 1], or with Scheduler In Audio Interrupt on in Max6, or with some specific 3rd party objects) spawning their own private threads (I can't think of any native Max object doing that, besides poly~ of course)
      hth aa