Parallel processing of multi-processor/multi-core processor -- microthread

The above two articles introduce two typical and simple parallel methods, and briefly introduce their performance and advantages and disadvantages. Here we will introduce another method:Micro-ThreadTo synchronize multiple parallel tasks.

Let's imagine the problem below the limit: To search for an element in a known-length huge linear table (such as a one-dimensional array), and all the elements in the table are unique. The processor we use now has two cores. According to the second parallel method described above, we can simply let kernel a search for the first half of the elements and let kernel B search for the last half of the elements. At that time, we processed the search operation as a separate thread. However, operations such as search often get results immediately after it ends, and then continue to do other things. At this time, this search operation will become a serial (sequential) part of a thread (task. This is also quite natural. However, this also brings about a problem: when one core finds the result, how to stop the search action of the other core and immediately process the subsequent tasks. I want to introduce a "micro-thread" concept to handle this situation more effectively.

Here, the "micro-thread" refers to the sub-interval of the stack space of the thread attached to the thread, in addition, the operations of the micro-thread are part of the job flow of the thread. Only after the operations of the micro-thread are completed can the rest of the thread be executed.

You can use the following model:

int ThreadA_Handler(void){    Initialize();    while(do_event(event_id1))    {        void* mem = AllocMemPool(MEM_SIZE_1024B);        Initialize_Resource(mem);        // Create micro-thread        int elem = StartMicroThread(                         /*thread id*/task_id_threadA,                         /*micro-thread handler*/&do_handlerMA,                         /*the argument for the handler*/mem,                         );        // Process the result        Output(elem);    }    return THREAD_SUCCESS;}

In the above Code, the startmicrothread () function is used to create the microthread interface. It records the ID of the current thread, which will be used for dispatching the microthread In the interrupt processing to be described later, passing the microthread processing function, and then passing it to the input parameter of the microthread.

The following describes the possible appearance of startmicrothread:

void* StartMicroThread(TASK_ID task_id, /*input*/                       void*(*pMicroThreadHandler)(void*),/*input*/                       void* pParam,  /*input*/                       ){    unsigned int context = sys_fetch_ret_address();    RegisterMicroThreadHandler(task_id, context);    void* ret = (*pMicroThreadHandler)(pParam);    return ret;}

In the above Code, the sys_fetch_ret_address () system function indicates to obtain the address to be returned by the current function, so that you can use an external event to directly cancel the micro-thread operation and go to startmicrothread () the next instruction address of the function call. Of course, you can add a bit of processing here to recycle the used stack space. Context protection and restoration can be added before and after startmicrothread () function calls (context Protection and Restoration here are nothing more than treasure pointer and frame pointer (called base pointer bp in x86) ).

Registermicrothreadhandler () is used to register the thread ID and return address. When one core notifies another core that the action has been completed and the other core immediately ends the micro-thread operation, the dispatcher checks whether the current active thread is a registered thread. If yes, set the return address of the interruption to the context value. Otherwise, set a flag for the thread and pass the context value to it, so that the micro-thread operation can be ended immediately when the thread is scheduled again. Therefore, this micro-thread concept is also based on the scheduling preprocessing mechanism, which is not used in many mainstream operating systems currently.

The third statement is to call a user-defined microthread processing function and then return the result. Here, the results may often be returned to a shared storage zone variable, because it is likely that the result is forcibly exited when the micro-thread operation is not complete, and the return value is not fixed. It may not be a good idea to set the return value here.

The following describes how to use macro functions to protect and restore stack context:

#define BEGIN_MICRO_THREAD(task_id, handler, param) {  /    SAVE_STACK_CONTEXT();    /    StartMicroThread(task_id, handler, param);    /    RESTORE_STACK_CONTEXT();    /}

The save_stack_context () and restore_stack_context () can be implemented according to the specific system. Of course, there is no problem in the form of Embedded Assembly.

Then, we may sometimes apply for storage resources, locks, or other resources in the microthread operation. In this case, we can also use some means to deal with resources not released due to forced termination. This problem is similar to the resource application and release operations in the thread. For details, refer. Such as the try-catch mechanism in C ++.

The last problem cannot be ignored. That is, after exiting the microthread processing function, the registered context should be deregistered. We can define another macro function --

#define END_MICRO_THREAD(task_id) {    /    UnregisterMicroThreadHandler(task_id);    /    // You may add some resource releasing function calls here    /}

In this way, two macro functions are used in pairs.

Next we will discuss some more specific operations in the microthread processing function.

Take the search operation as an example. In this mechanism, we basically need to determine the core of the thread affiliated to the microthread that obtains the result. In this regard, the micro-thread mechanism is more suitable for embedded systems. Another micro-thread is used as an auxiliary computing operation. Generally, an interrupt request signal is sent to the core of the thread to obtain the result. When the thread completes the operation and the result is not completed. When the microthread that obtains the result completes the operation but does not obtain the operation result (for example, the specified data is not found), it has to wait for the operation of another core to complete. Therefore, this micro-thread will actually end its operations only when appropriate results are obtained, and then the thread continues to execute. This is also the reason why only one thread ID is required for the function to register and deregister the context, and no other flag is required.

The microthread used as the auxiliary computing can be scheduled to the same core as the microthread that obtains the result. In this case, the efficiency will not be reduced, especially when another core is always busy processing other transactions and cannot be scheduled to the thread to which the micro-thread belongs for a long time.

Finally, for the implementation of micro-thread processing functions can also be referred to: http://download.csdn.net/source/297300