Patent Publication Number: US-2005125789-A1

Title: Executing processes in a multiprocessing environment

Description:
The invention relates to a method, and a corresponding system, of executing processes with different priorities in an operating system run by a computing device. More particularly, the invention relates to a method, and a corresponding system, of executing processes with different priorities using a shared resource in an operating system providing a multiprocessor or multiprocessing environment.  
      Software of hard or critical real-time systems typically comprises a high priority thread, process, task, job, etc. (these terms are used interchangeably throughout the text) responsible for performing time-critical actions or processing. Usually, such systems also comprise a thread of lower or low priority responsible for performing background actions or processing.  
      The processing of the low priority thread may be pre-empted by the high priority thread and by other thread(s) (called intermediate priority thread(s) in the following) whose priority lies between that of the high priority thread and the low priority thread.  
      A thread, task, process or job is a part of a program that can execute independently of other parts. Operating systems that support multithreading enable programmers to design programs whose threaded parts can execute concurrently.  
      Threads with different or same priority may communicate through or use a shared resource like a memory or file, part of a memory or file, etc. Access to a shared resource is typically protected or handled by a program object that ensures that only one thread is allowed to access the given resource, e.g. so that one thread does not try to read from a memory before (or while) another thread has finished writing data to it or vice versa. Such a program object is usually called a mutex, which is short for ‘mutual exclusion object’. A mutex is a program object that allows multiple program threads to share the same resource, such as file and memory access, but not simultaneously. When a program is started, a mutex is created with a unique name, identifier, etc. for each shared resource that is used by multiple threads. After this stage, any thread that needs the resource must ‘lock’ the mutex from other threads while it is using the resource. The mutex is unlocked, released, etc. when the data, resource, etc. is no longer needed or the routine is finished. A mutex may be implemented by a semaphore or a binary semaphore, which typically is a hardware or software flag. In multitasking systems, a semaphore is typically a variable with a value that ‘locks’ or indicates the status of a common resource. It is used to obtain information of the resource that is being used. A process needing the resource checks the semaphore to determine the resource&#39;s status and then decides how to proceed, e.g. with getting or locking an appropriate mutex.  
      A problem may arise when a high priority thread and a low priority thread communicate through or use a shared resource that prevents the high priority thread to access the shared resource for too long thereby preventing the high priority thread to perform it&#39;s time-critical task as explained in the following. Suppose that the low priority thread ‘owns’ access to the shared resource at a given time and the high priority thread then needs to access the shared resource thereby having to wait until the low priority thread is done. In this situation, an intermediate priority thread (that does not have to use the particular shared resource) may then delay the access of the high priority thread by preempting the low priority thread thereby extending the time that the high (and low) priority thread has to wait by an amount of time equal to the time that the intermediate priority thread uses, which may cause the high priority task to fail performing it&#39;s actions in due time.  
      This problem is usually referred to in the literature as ‘priority inversion’ and is explained in greater detail in connection with  FIG. 1   a.    
      One previous solution to this particular problem is to implement a ‘priority inheritance’, sometimes called ‘priority promotion’, mechanism where an owning thread temporarily (e.g. the low priority thread) gets a priority equal to the highest priority of the waiting processes/threads. In this way, no intermediate priority process is able to pre-empt the low priority thread and thus delay the waiting time further for the high priority thread.  
      The Priority Inheritance mechanism has two problems as e.g. disclosed in “Missed it!—How Priority Inversion messes up real-time performance and how the Priority Ceiling Protocol puts it right”, N. J. Keeling (Real-Time Magazine 99-4, 1999). One problem arises when a high priority thread shares multiple resources with other threads, that causes priority inheritance to take too much time, and another problem may arise if multiple threads share multiple resources with each other, whereby priority inheritance will not prevent a deadlock if threads allocate the resources in the wrong order. A solution, called ‘priority ceiling’, to these two problems is proposed in Keeling where an owning thread temporarily gets a priority equal to the highest priority of all threads that are allowed to wait for the mutex of the shared resource.  
      However, a priority inheritance and a priority ceiling mechanism can not always be used for communication via a shared resource between a high priority thread and a low priority thread whereby an intermediate priority thread (having a priority between the high and low priority thread) may prevent the high priority thread from performing it&#39;s actions in time thereby possibly rendering real-time application useless, erroneous, etc. Additionally, the option of a priority inheritance or a priority ceiling mechanism may not always be available or supported e.g. due to restrictions imposed by an operating system running the thread(s). As an example, if e.g. two different operating systems are running on a single processor at a given time, where one of the operating systems is a real-time operating system running the high priority thread and the other operating system is a non-real time system running the low priority thread, then the priority of the low priority thread can not be raised high enough to reach the priority of the high priority thread.  
      It is an object of the invention to provide a method and system of executing processes with different priorities in a multiprocessing environment where the method and system solves the problems of the prior art.  
      This is achieved by a method of executing processes with different priorities in a multiprocessing environment comprising execution of a low priority process and a high priority process where the high priority process and the low priority process share a given resource, characterized in that the method comprising the step of: raising an effective priority of the low priority process when the low priority process is going to use the shared resource, where the effective priority is raised to be above a priority of an other process in the multiprocessing environment.  
      In this way, a high priority process will only be delayed, by other processes, for as short a time as possible so that it will be able to execute it&#39;s tasks in due time and no other process, than the high priority, may stall the access of the low priority process to the given resource due to that the ‘effective’ priority is raised.  
      The effective priority may be raised until the high priority thread has finished other tasks.  
      No support from the operating system or operating systems can be required other than basic synchronisation and communication means and a strict priority scheme, where a thread cannot be pre-empted by threads with the same or a lower priority.  
      A preferred embodiment is described in claim  2 . In some further embodiments, the additional process may be synchronised with the high priority process, e.g. using a mutex, a Boolean or a semaphore.  
      In this way, the raising of the ‘effective’ priority of the low priority process is achieved by using an additional thread accessing the given resource on behalf of the low priority (which stays at the same low priority) and communicating with the high priority process, where the additional process may not be stalled, preempted, etc. by other processes other than the high priority process.  
      An other preferred embodiment is described in claim  6 . Alternatively, the effective priority is raised to be equal of greater than the priority of the high priority process.  
      Preferably, the operating environment is a pre-emptive environment.  
      In one embodiment, the multiprocessor environment comprises a real-time operating system and a non-real time operating system running on a single processor at least at a given time, where the real-time operating system comprises said high priority thread and said additional process and where the non-real time operating system comprises said low priority thread.  
      In this way, the multiprocessing system has two sets of threads or processes. All threads compete for time on the same CPU. The threads in the first set are scheduled with strict priority: a thread will not get CPU time if there is a thread with higher priority that needs CPU time as well. The threads in the second set will only get CPU time if none of the threads in the first set needs CPU time. So effectively all threads in the first set have higher priority than the threads in the second group. Threads cannot migrate between the sets. All threads can share memory and use semaphores and mutexes amongst each other.  
      As an example, the first set may e.g. be scheduled by RTX (=Real Time Extension, by VenturCom Inc.). This set may be used for threads like the high priority thread that do real-time processing. The second set may e.g. be scheduled by Windows NT (by Microsoft). This set may be used for threads like the low priority thread doing background processing and control processing.  
      This object is further achieved by a system for executing processes with different priorities in a multiprocessing environment comprising means adapted to execute a low priority process (T 1 ) and a high priority process (T 4 ) where the high priority process (T 4 ) and the low priority process (T 1 ) share a given resource (SM 4 ), characterized in that the system comprises: 
          means for temporarily raising an effective priority of the low priority process (T 1 ) when the low priority process (T 1 ) is going to use the shared resource (SM 4 ), where the effective priority is raised to be above a priority of an other process (T 1 , T 2 ) in the multiprocessing environment.        

      Other preferred embodiments of the invention are defined in the sub claims. 
    
    
       FIG. 1   a  illustrates execution of various threads having different priority according to prior art;  
       FIG. 1   b  illustrates execution of various threads having different priority according to the present invention;  
       FIGS. 1   c  and  1   d  illustrates execution of various threads having different priority according to alternative embodiments of the present invention;  
       FIG. 2   a  illustrates an embodiment of the method according to the present invention, where a high priority thread (T 4 ) tries to access the shared resource while a low priority thread (T 1 ) already has access to it;  
       FIG. 2   b  illustrates an embodiment of the method according to the present invention where a high priority thread does not try to access the shared resource while a low priority thread already has access to it;  
       FIG. 3  illustrates a flowchart for an embodiment of an additional thread (T 3 ) according to the present invention;  
       FIG. 4  illustrates a system according to the present invention.  
    
    
       FIG. 1   a  illustrates the execution of various threads having different priority according to prior art. Shown is a high priority thread, process, task, job, etc. (T 4 ) e.g. performing time-critical actions, a low or relatively lower priority thread (T 1 ) e.g. performing background processing, and an intermediate priority thread (T 2 ) having a priority between T 1  and T 4 . All the threads are being executed in an operating system providing a multiprocessor or multiprocessing environment where only a single thread is active at a time. The figure illustrates when the threads (T 4 , T 2 , T 1 ) are active as a function of time. The high priority (T 4 ) and the low priority thread (T 1 ) uses a shared resource like a memory where the access to the shared resource is protected by a mutex (M). ‘wg’ indicates a ‘wait/get mutex (M)’ instruction, command, etc. and ‘r’ indicates ‘release mutex (M)’.  
      At the start of the timeline, thread (T 1 ) is executing and at time  1  thread (T 1 ) executes a ‘wg’ instruction indicating that thread (T 1 ) wants to use the shared resource e.g. because it needs to write into the shared (between T 1  and T 4 ) memory. Since the mutex (M) at time  1  is not ‘owned’ by or allocated to another process, then thread (T 1 ) gets to own the mutex and thereby access to the shared resource until it releases it. At time  2 , thread (T 1 ) is pre-empted by the higher priority thread (T 4 ) and at time  3 , the thread (T 4 ) issues a ‘wg’ instruction since it tries to access the shared resource, e.g. for reading from a shared memory. Since the mutex (M) is owned by another process at that time, thread (T 4 ) has to wait until the mutex (M) is released and thread (T 1 ), that was pre-empted, continues e.g. with writing to the shared memory. At time  4 , another thread (T 2 ) having a priority lower than T 4  but higher than (T 1 ) is initiated or activated before T 1  is finished using the shared resource. This thread (T 2 ) pre-empts T 1  due to the higher priority and is executed until it finishes at time  5 . Thread (T 2 ) is not pre-empted by T 4  since T 4  is in a wait state because the mutex (M) is owned by another thread and has not been released. Thread (T 2 ) does not, in this particular example, use the resource that T 4  and T 1  share.  
      At time  5 , thread (T 2 ) is done and thread (T 1 ) becomes active. At time  6 , thread (T 1 ) is done using the shared resource and releases the mutex (M) after which T 4  is able to get the mutex (M) and thereby access to the shared resource. At time  7 , thread (T 4 ) is done using the shared resource and releases the mutex (M) and thread (T 1 ) is activated again.  
      So in this way, a high(er) priority thread (T 4 ) may be locked, delayed, prevented from executing and/or accessing a shared resource, etc. by a thread (T 2 ) with a lower priority but having a higher priority than a thread (T 1 ) that (T 4 ) shares the resource with. This is very unfortunate, especially for high priority threads responsible for time-critical tasks since they may be unable to perform these time-critical actions.  
       FIG. 1   b  illustrates execution of various threads having different priority according to the present invention. Shown is a high priority thread, process, task, job, etc. (T 4 ) e.g. performing time-critical actions, a low or relatively lower priority thread (T 1 ) e.g. performing background processing, an intermediate priority thread (T 2 ) having a priority between T 1  and T 4 , and an additional thread (T 3 ) having a priority lower than T 4  but higher than the other threads (T 1  and T 2 ). The figure illustrates when the threads (T 4 , T 3 , T 2 , T 1 ) are active as a function of time. At time  1  the low priority thread (T 1 ) indicates that it wants to access a resource that it shares with the high priority thread (T 4 ). This indication may e.g. be done by using or setting a semaphore. When this indication occurs, the additional thread T 3 , having a priority lower than T 4  but higher than the other threads (T 1  and T 2 ), pre-empts T 1  and performs, at time  2 , the actual execution of a ‘wg’ instruction in order to access the shared resource whereby a mutex (M) for the shared resource is locked, reserved, etc. In this way, T 3  accesses the shared resource on behalf of T 1 , i.e. T 1  will not access the shared resource directly. T 3  and T 1  are synchronized, at time  1 , as indicated by the ‘s’, preferably using a semaphore. Usually, semaphores are used to synchronise and a shared resource or memory is used for communication. Alternatively, message passing may be used where the message(s) communicate the information and the sending or receiving of a message can be used for synchronisation.  
      At time  3 , the high priority thread T 4  pre-empts T 3  and before time  4  it tries to access the shared resource. However, since the shared resource is already in use by T 3  (on behalf of T 1 ), T 4  goes into a wait state after issuing a ‘wg’ instruction at time  4 . Since T 4  is waiting ‘w’, T 3  (having the next highest priority) resumes execution. At time  5 , T 3  is done using the shared resource and issues a release instruction ‘r’ for the mutex (M), after which T 4  pre-empts T 3  and gets or locks ‘g’ the mutex (M) so that it may access the shared resource. At time  6 , T 4  is done using the shared resource and releases ‘r’ the mutex ( ). At time  7 , T 4  is done executing its e.g. time-critical task and T 3  becomes active. At time  8 , T 3  is finished and is synchronized with T 1  once again e.g. as indicated by using/setting a semaphore, using message passing, etc., after which the thread T 2  pre-empts T 1  and executes until it is finished at time  9  whereby T 1  resumes.  
      T 3  and T 1  may communicate by any appropriate mechanism, e.g. via shared memory and/or using semaphores. T 3  will own the mutex (M) as short as possible since it can only be pre-empted by T 4  (and not by any intermediate threads like T 2 ) and will not wait for T 1  as long as it owns the mutex (M). Normally, T 3  could wait for T 1  if T 1  has not yet given any instructions or information to T 3  by waiting for e.g. a semaphore that will eventually be released by T 1 . However, this will not occur when T 3  accesses the mutex (M) on behalf of T 1 .  
      In general, T 4  may still be blocked by T 3  for a short while after T 4  is in a wait state for the shared resource and until T 3  has finished using the shared resource, but during this time T 3  will not be stalled by T 1  (or indirectly by T 2 ).  
      In general, T 1  is given an ‘effective’ priority that is higher when it needs to access the shared resource. This is in one embodiment achieved by using an additional thread (T 3 ) with a priority below T 4  and above other threads (T 1  and T 2 ) where T 1  and T 3  are synchronised and where T 3  accesses the shared resource on behalf of T 1 .  
      In this way, it is not possible for an intermediate thread (T 2 ), that does not use the resource shared between T 1  and T 4 , to delay the high priority thread (T 4 ) thereby ensuring that the e.g. time-critical tasks of the high priority thread is executed in time.  
      In one embodiment, the priority of T 3  just needs to be between T 4  and the rest (T 1  and T 2 ). However a new process with a new priority greater than T 1 , T 2  and T 3  may delay T 4  like described in connection with  FIG. 1   a . So, preferably, the priority of T 3  is slightly lower than that of T 4  and higher than the others (T 1  and T 2 ). In this way, no other processes than T 4  may pre-empt T 3  and thus delay T 4  further.  
      In an alternative embodiment, the effective priority of the low priority thread (T 1 ), e.g. implemented by an additional thread T 3  synchronised and accessing the shared resource on behalf of T 1 , is raised to be equal to or alternatively higher than the priority of T 4 . Let us call such a thread T 5 . However, such a thread should be programmed with great care since it may spoil the real-time performance of T 4 . However, typically T 5  uses little CPU time for the purpose according to the present invention. These alternatives are shown in  FIG. 1   c  (effective priority raised above T 4 ) and  FIG. 1   d  (effective priority equal to that of T 4 ). In  FIG. 1   d  a full line indicates T 4  and a broken line T 5  and the bracers indicates when which thread (T 4  or T 5 ) is active. Here it is shown that T 4  and other threads (T 2 ) may not pre-empt T 5  after time  1  where T 1  is syncrhonised with the additional thread (T 5 ). T 5  waits, gets and releases the mutex (M) at time  2  and  3 . At time  4  T 4  becomes active and waits, gets, and releases the mutex (M) at time  5  and  6 , before T 2  and T 1  becomes active at time  7  and  8 , respectively. In this way any additional threads (T 2 ) does not delay the time critical thread (T 4 ). In the case when T 4  and T 5  have the same priority ( FIG. 1   d ), T 4  can still not preempt T 5  in some operating systems e.g. like RTX. If T 4  happens to have an important task at exactly, which is quite unlikely, time  1  either T 4  or T 5  may start. If T 4  starts before T 5  it finishes its time-critical task(s) before T 5  accesses the shared resource on behalf of T 1  after which T 4  will access the shared resource like illustrated in  FIG. 1   d  (time  1  to time  7 ). If T 5  starts before T 5  it corresponds to the situation shown in the Figure.  
       FIG. 2   a  illustrates an embodiment of the method according to the present invention, where a high priority thread (T 4 ) tries to access the shared resource while a low priority thread (T 1 ) already has access to it. The method starts at step ( 200 ). At step ( 201 ) the processes/threads in the multi-process environment are executed normally according to their priority. At step ( 202 ) a test, indication, etc. is made whether the low priority thread (T 1 ) needs to access the shared resource, like a shared memory (SM). If this is not the case the method executes processes normally at step ( 201 ). If this is the case, the method proceeds to step ( 203 ) where the ‘effective’ priority of T 1  is raised according to the present invention. At step ( 204 ), T 1  secures access to the shared resource, e.g. by getting a mutex (M) for the shared resource, and T 1  starts using SM. At step ( 205 ) it is determined if the high priority thread (T 4 ) tries to access the shared resource while T 1  owns the mutex (M). If this is the case, T 4  waits for the mutex (M) to be released and enters a wait state at step ( 206 ). If T 4  does not need access to the shared resource (SM) or T 4  is waiting, T 1  finishes with and releases the mutex (M) for the shared resource (SM) at step ( 207 ). After T 1  is finished with the shared resource (SM), it is determined if T 4  waits at step ( 208 ). If this is not the case, T 1  finishes it&#39;s processing (involving other things than access to the shared resource (SM)) and the ‘effective’ priority for T 1  is lowered to its normal low priority. The ‘effective’ priority may be lowered immediately after T 1  is done using the shared resource (SM) (step ( 207 )) and before T 1  finishes any other tasks. After step ( 209 ) the method proceeds to step ( 201 ) where processes are run normally. If T 4  did wait at step ( 208 ), T 4  pre-empts T 1  and secures the access to the shared resource (SM), e.g. by getting the mutex (M) at step ( 210 ), after which, T 4  finishes with SM, at step ( 211 ), and possibly with other tasks, at step ( 212 ), before proceeding to step ( 209 ).  
      In this way, no other processes, threads, etc. (other than T 4 ) may pre-empt T 1  after step ( 203 ), thereby ensuring that T 4  does not get stalled for too long. It may happen that T 4  wants access to the shared resource after step ( 203 ) and before step ( 204 ). In this case it will immediately get the mutex, use the shared resource, and release the mutex again. One way of avoiding that T 4  pre-empts T 1  (or T 3 ) is by having an effective priority equal or higher than the priority of T 4  as illustrated in connection with  FIG. 1   c  and  1   d.    
      If the step of raising the ‘effective’ priority for T 1  is implemented, as explained above and in the following, using an additional thread (T 3 ) accessing the shared resource on behalf of T 1  and having a priority below T 4  and above the other processes step ( 203 ) would invoke T 3  on behalf of T 1  and in the steps ( 204 ,  207 ,  209 ) it would read T 3  instead of T 1 . T 1  and T 3  would preferably be synchronised at step ( 203 ) and step ( 209 ). This implementation is explained in greater detail in connection with  FIG. 3 .  
       FIG. 2   b  illustrates an embodiment of the method according to the present invention where a high priority thread (T 4 ) does not try to access the shared resource while a low priority thread (T 1 ) already has access to it. The steps ( 220 - 224 ;  225 ) correspond to the step ( 200 - 204 ;  207 ) in  FIG. 2   a . After T 1  has released access to the shared resource (SM) at step ( 225 ) a signal, indication, etc. is given, at step ( 226 ), to T 4  that information, data, etc. waits e.g. using a Boolean (B 4 ), a semphore or massage passing.  
      At step ( 227 ), T 4  pre-empts T 1  and secures the access to the shared resource, e.g. by getting the mutex (M) and at step ( 228 ), T 4  uses and releases the resource (SM). At step ( 229 ), T 4  finishes other tasks not related to accessing the shared resource (SM), if any. At step ( 230 ), T 1  resumes execution and finishes. The ‘effective’ priority is lowered (may also be done at step ( 225 ) and the method returns to step ( 221 ). However, it is not as advantageously to reduce the ‘effective’ priority at step ( 225 ) instead of step ( 230 ), since T 2  may pre-empt T 1  before step ( 226 ), so it may take a longer time before T 4  is signalled.  
      If the step of raising the ‘effective’ priority for T 1  is implemented, as explained above and in the following, using an additional thread (T 3 ) accessing the shared resource on behalf of T 1  and having a priority below T 4  and above the other processes step ( 223 ) would invoke T 3  on behalf of T 1  and in the steps ( 224 ,  225 ,  226 ,  230 ) it would read T 3  instead of T 1 . T 1  and T 3  would preferably be synchronised at step ( 223 ) and step ( 230 ). T 3  and T 4  would preferably be synchronised at step ( 226 ) if needed e.g. using the mutex (M) or a Boolean (B 4 ) and a semaphore (S 4 ). However, T 3  and T 4  do not have to be synchronised in all cases, since for some applications it is sufficient that T 4  simply is signalled that information waits. This implementation is explained in greater detail in connection with  FIG. 3 . Alternatively, the raising of the ‘effective’ priority may be implemented by a thread having a priority equal to or greater than the priority of T 4  as described elsewhere.  
       FIG. 3  illustrates a flowchart for an embodiment of an additional thread (T 3 ) according to the present invention. In this particular embodiment, the additional thread (T 3 ) communicates (on behalf of the low priority thread (T 1 )) with the high priority thread (T 4 ) via a shared memory (SM 4 ) that is protected by a mutex (M) and synchronized by a Boolean (B 4 ) and a semaphore (S 4 ). T 3  communicates with the low priority thread (T 1 ) via a shared memory (SM 1 ) that is synchronized by semaphores S 1 A and S 1 B. In this particular example, information, data, etc. is to be transferred from the low priority thread (T 1 ), using a shared memory (SM 1 ), to the high priority thread (T 4 ), using a shared memory (SM 4 ), via the additional thread (T 3 ).  
      At step ( 301 ) the method is initialised where processes and initial values for parameters, etc. are set up. In this particular example the Boolean ( 14 ) is set to false indicating that no information, data, etc. is ready/available for T 4 .  
      At step ( 303 ) the embodiment of T 3  waits for an indication that T 1  needs to send information to/communicate with T 4 . Other processes (including T 1  and T 3 ) may be run normally during the waiting. The waiting may e.g. be done by waiting for a semaphore (S 1 A), i.e. to wait for that T 1  has accessed the shared resource (SM 1 ) and e.g. put info or data in the shared memory (SM 1 ), and second to wait for the mutex (M) to be released. After/if the mutex (M) is available it is reserved/held by T 3  so that T 3  may access the shared memory (SM 4 ). At step ( 304 ) content from the shared memory (SM 1 ) is copied to the shared memory (SM 4 ). After the information is transferred the mutex (M) is released so that other processes may use the shared resource. At step ( 305 ) the Boolean (B 4 ) is set to ‘true’ in order to signify to T 4  that there is information available. At step ( 306 ) the method waits for the semaphore (S 4 ) signifying whether T 4  has accessed/used the information, data, etc. in the shared memory (SM 4 ). After T 4  has used the information, the semaphore (S 1 B) is released, at step ( 307 ), signifying to T 1  that the shared resource (SM 1 ) may be used for other purposes, i.e. that T 4  is done, after which the method starts over until a new communication needs to be made.  
      The pseudo code for this exemplary embodiment of the additional thread (T 3 ) is:  
                                                  Boolean B4 := false           while forever do           {                              wait for S1A;   // Wait until T1 has put info in SM1.            wait for M;                          copy SM1 to SM4;                              release M;                B4 := true;   // Tell T4 that there is info.            wait for S4;   // Wait until T4 has used info in SM4.            release S1B;   // Tell T1 that SM1 can be filled with               // other info.           }                      
 
      In this embodiment, T 4  will usually often (e.g. in a while loop) do: if (B 4 =true)  
                                                  if (B4 == true)           {            B4 := false;            wait for M;            use info in SM4;            release M;            release S4;           }                      
 
      B 4  and S 4  provide an extra synchronisation that may be useful in some applications, although making the embodiment more complex. Alternatively, B 4  and S 4  may be removed from the embodiment.  
      Alternatively, the method may use cyclic buffers and/or different synchronization means or schemes. Additionally, the copy action ( 304 ) from SM 1  to SM 4  may be omitted or replaced with another action (e.g. a copy action from SM 4  to SM 1  if information is to be transferred from T 4  to T 1 , etc.), since it is only used for transferring data from T 1  to T 4 . Another example is using ‘remote procedure call’, where first procedure parameters are copied from T 1  to T 4 , then T 4  executes a procedure, and then the procedure copies the result back to T 1 . This however, requires more synchronization than in the above example. It can also be made to work in the opposite direction.  
      In the context of this exemplary embodiment for T 3 ,  FIG. 1   b  may represent a situation where T 1  writes data, information, and etc. (via T 3 ) into a shared memory (SM 4 ) in order for T 4  to read but where T 4  tries to access the shared memory (SM 4 ) before T 1  has done writing to it.  
      The lines of the pseudo code may correspond to the times of  FIG. 1   b  according to:  
                                                      { wait for S1A;   (Corresponds to T = 1)            wait for M;   (T = 2)            copy SM1 to SM4;   (Between T = 2 and T = 5)            release M;   (T = 5)            B4 := true;   (Before T = 7)            wait for S4;   (T = 7)            release S1B;   (T = 8)}                      
 
      ‘B 4 :=true’ is actually not used in the situation in  FIG. 1   b  since T 4  already tries to get access to SM 4  before T 1  (T 3 ) is finished. Otherwise this would signal to T 4  that it should access SM 4  in order to retrieve information.  
       FIG. 4  illustrates a schematic block diagram of an embodiment of a system according to the present invention. Shown is a system ( 400 ) according to the present invention comprising one or more micro-processors ( 401 ) connected with a memory and/or a storage ( 402 ) and other devices or functionalities ( 403 ) via a communications bus ( 404 ) or the like. The micro-processor(s) ( 401 ) is(are) responsible for executing the various processes, threads, etc. (T 1 , T 2 , T 3 , T 4 ), for executing the method according to the present invention as well as other software like operating system(s), specialised programs, etc. using the threads, and for synchronising the threads according to the present invention.  
      The memory or storage ( 402 ) comprises a shared resource ( 402 ′) like a shared memory (SM 4 ) or file or part thereof, shared by the threads T 4  and T 3 , and another shared memory (SM 1 ) or file, shared by threads T 3  and T 1 ). The shared resource may e.g. be a shared Input/Output (I/O) device, e.g. comprising a memory, where one thread may write to the memory and another may read from it. Indicated, is also which synchronisation means that is used with respect to synchronising the various threads for the exemplary embodiment described in connection with  FIG. 3 . For SM 4  it is a Boolean ( 134 ) and a semaphore (S 4 ) where a mutex (M) controls the access to SM 4 , and for SM 1  it is a first semaphore (S 1 A) and a second semaphore (S 1 B).  
      The other devices or functionalities ( 403 ) may e.g. be a display, a communication device, a network device, etc.  
      One example of a system that may use the present invention is e.g. a MPEG-2 re-multiplexing device that may be used in cable systems, terrestial systems, satellite systems, etc. that broadcast Digital Video, etc. Also a receiver of digital video or audio like a set-top box or digital television set can comprise the system according to the invention. The MPEG-2 streams are processed in real-time by software threads that run under a real-time operating system e.g. RTX. Typically much of the control software runs on the same processor under a non real-time operating system e.g. Windows NT. A high priority thread (T 4 ) may be such a stream processing thread under the real-time operating system RTX and a low priority thread (T 1 ) may be a control processing thread under Windows NT. RTX does offer priority promotion, but this is not available between threads on RTX and threads on Windows NT. So according to the present invention it is avoided that a time-critical thread (T 4 ) is stalled for a long time by intermediate priority threads (T 2 ) like Windows NT interrupts, deferred procedure calls, etc. In this way, communication of control commands from Windows NT threads to RTX threads, communication of error messages from RTX threads to Windows NT threads, etc. is achieved without the above-mentioned drawbacks.