A multi-thread control method and a terminal device
By setting a shared lock in the first thread and executing the target operation in the second thread, the thread inconsistency problem in the asynchronous environment in the Android system is solved, ensuring the order execution of camera operations and the improvement of user experience.
Patent Information
- Application Number
- CN202111577798.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-22
- Publication Date
- 2025-07-29
- Estimated Expiration
- 2041-12-22
AI Technical Summary
In android system, thread inconsistency of camera operations in asynchronous environments leads to program disorder, and the existing technology cannot effectively solve abnormal problems in all cases through delayed operations.
By setting the initial value of the shared lock in the first thread and blocking, the second thread performs the target operation and sets the target value of the shared lock upon success, the first thread wakes up to ensure the order of the operation.
It realizes that operations of different threads in an asynchronous environment are executed in the same thread in sequence, avoids exceptions and improves the real-time operation and user experience.
Smart Images

Figure CN114356559B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of microprocessors, and particularly to a multi-thread control method and a terminal device. Background Art
[0002] In the Android system, a set of camera APIs based on the Camera1 framework (i.e., application programming interfaces for a terminal device to call the camera in the terminal) is proposed. In this API, the opening and preview of the camera are sequentially performed in the same thread, and the camera preview must be performed after the camera is successfully opened.
[0003] Afterwards, a new camera framework, namely Camera2, emerged. Among them, the opening of the camera and the camera preview, etc. all have a callback to notify the user of the final execution result of this operation. If the execution result is successful, the user can continue to perform subsequent operations; and in Camera2, the opening of the camera is in the first thread, while the execution program and callback of the opening of the camera are in the second thread, so that the operation of the camera will not affect other business processes. This improvement is usually very helpful for performance improvement.
[0004] In the Android system, to process images and implement various image effects, OpenGL (Open Graphics Library) is required. OpenGL needs to display images in a GLSurfaceView; the interface provided by GLSurfaceView.Renderer (i.e., the GLSurfaceView renderer) can render the graphics drawn by OpenGL into the SurfaceView. The Renderer (i.e., the renderer) is called in a separate thread, and the rendering operation is decoupled from the interface thread to prevent the main thread from being blocked when processing images, giving the user a feeling of lag; among them, this requires that both the opening and preview of the camera must be performed in the same thread.
[0005] Moreover, if the opening and preview of the camera need to be performed in a certain thread, and the specific programs for implementing the opening and preview of the camera are executed in another thread, without synchronizing the two threads, the program will be disordered due to asynchrony.
[0006] In addition, based on Camera2, if the opening of the camera is required in a certain thread (assumed to be thread A), but the callback for whether the opening of the camera is successfully executed is in another thread (assumed to be thread B), the following problems will occur:
[0007] 1. If the camera preview is required in thread A, it is possible that when the preview is executed, the camera has not been opened yet, resulting in an exception in the camera.
[0008] 2. If camera preview is required in Thread B, this does not meet the requirement mentioned above that both opening the camera and camera preview must be performed in the same thread.
[0009] Therefore, how to avoid program chaos in an asynchronous environment is a technical problem that needs to be solved urgently by those skilled in the art. Summary of the Invention
[0010] Embodiments of the present invention provide a multi-thread control method and a terminal device to avoid program chaos in an asynchronous environment.
[0011] In a first aspect, embodiments of the present invention provide a multi-thread control method, including:
[0012] When a target operation needs to be performed on a device in a first thread, control the first thread to be in a blocked state, and in the first thread, set the status flag of the shared lock to an initial value;
[0013] Execute a program for implementing the target operation in a second thread. If the result obtained after execution is successful, in the second thread, set the status flag of the shared lock to a target value;
[0014] When it is determined in the first thread that the status flag of the shared lock is the target value, wake up the first thread.
[0015] In a second aspect, embodiments of the present invention provide a multi-thread control device, including:
[0016] A memory for storing program instructions;
[0017] A processor for calling the program instructions stored in the memory and executing the above multi-thread control method provided by the embodiments of the present invention according to the obtained program.
[0018] In a third aspect, embodiments of the present invention provide a readable storage medium, which stores executable instructions for a multi-thread control device. The executable instructions for the multi-thread control device are used to make the multi-thread control device execute the above multi-thread control method provided by the embodiments of the present invention.
[0019] In a fourth aspect, embodiments of the present invention provide a terminal device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the steps of the above multi-thread control method provided by the embodiments of the present invention.
[0020] The beneficial effects of the present invention are as follows:
[0021] An embodiment of the present invention provides a multi-thread control method and terminal device. If it is necessary to perform a target operation on the device in the first thread, the first thread can be controlled to be in a blocked state so that the first thread will not continue to execute subsequent operations; at this time, the program for implementing the target operation can be executed in the second thread, and the status mark of the shared lock can be set in the second thread according to the execution result; further, it can be determined whether the first operation is successfully executed according to the status mark of the shared lock. If the execution is successful, the first thread is awakened again, the blocking state of the first thread is released, and the subsequent operations can be continued in the first thread; at this time, when executing subsequent operations in the first thread, since the previous target operation is executed successfully, the subsequent operations can be carried out normally and no abnormal phenomena will occur, thereby avoiding adverse effects on subsequent operations, thereby realizing the sequential execution of operations of different threads under the same thread in an asynchronous environment, avoiding abnormalities caused by asynchronous operations in the asynchronous environment. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Figure 1 The following is a schematic diagram showing the structure of a terminal device provided by an embodiment of the present invention;
[0023] Figure 2 The following is a schematic diagram illustrating a software architecture of a terminal device provided by an embodiment of the present invention;
[0024] Figure 3 The following is a flowchart illustrating a multi-thread control method provided by an embodiment of the present invention;
[0025] Figure 4 A flowchart of an embodiment of the present invention is exemplarily shown;
[0026] Figure 5 A flowchart of another embodiment provided by an embodiment of the present invention is exemplified;
[0027] Figure 6 The schematic diagram exemplarily shows the structure of a multi-thread control device provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0028] The following is a clear and detailed description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. In the description of the embodiments of the present invention, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text is only a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present invention, "multiple" means two or more than two.
[0029] Hereinafter, the terms "first" and "second" are for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present invention, unless otherwise specified, the meaning of "a plurality" is two or more.
[0030] In addition, the terms "comprising" and "having" and any variations thereof are intended to cover but not exclude inclusion. For example, a product or device comprising a series of components need not be limited to those components clearly listed, but may include other components not clearly listed or inherent to such products or devices.
[0031] The term "module" used in the present invention refers to any known or later-developed hardware, software, firmware, artificial intelligence, fuzzy logic, or a combination of hardware or / and software code that can perform functions related to that element.
[0032] Figure 1 The structural schematic diagram of the terminal device 100 is shown.
[0033] Hereinafter, the embodiments will be specifically described by taking the terminal device 100 as an example. It should be understood that Figure 1 the illustrated terminal device 100 is merely an example, and the terminal device 100 may have more or fewer components than those Figure 1 shown, may combine two or more components, or may have different component configurations. The various components shown in the figure may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.
[0034] Figure 1 The hardware configuration block diagram of the terminal device 100 according to an exemplary embodiment is exemplarily shown in. As Figure 1 shown, the terminal device 100 includes: a Radio Frequency (RF) circuit 110, a memory 120, a display unit 130, a camera 140, a sensor 150, an audio circuit 160, a Wireless Fidelity (Wi-Fi) module 170, a processor 180, a Bluetooth module 181, and a power supply 190, etc.
[0035] The RF circuit 110 can be used for receiving and transmitting signals during information reception and transmission or calls. It can receive downlink data from the base station and hand it over to the processor 180 for processing; it can send uplink data to the base station. Generally, the RF circuit includes, but is not limited to, devices such as antennas, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, and a duplexer.
[0036] The memory 120 can be used to store software programs and data. The processor 180 executes various functions and data processing of the terminal device 100 by running the software programs or data stored in the memory 120. The memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices. The memory 120 stores an operating system that enables the terminal device 100 to operate. In the present invention, the memory 120 can store the operating system and various application programs, and can also store the code for executing the method described in the embodiments of the present invention.
[0037] The display unit 130 can be used to receive input digital or character information and generate signal inputs related to the user settings and function control of the terminal device 100. Specifically, the display unit 130 may include a touch screen 131 disposed on the front surface of the terminal device 100, which can collect touch operations of the user thereon or nearby, such as clicking a button, dragging a scroll bar, etc.
[0038] The display unit 130 can also be used to display the information input by the user or the information provided to the user, as well as the graphical user interface (GUI) of various menus of the terminal 100. Specifically, the display unit 130 may include a display screen 132 disposed on the front surface of the terminal device 100. Among them, the display screen 132 can be configured in the form of a liquid crystal display, a light-emitting diode, etc. The display unit 130 can be used to display various graphical user interfaces described in the present invention.
[0039] Among them, the touch screen 131 can cover the display screen 132, or the touch screen 131 and the display screen 132 can be integrated to implement the input and output functions of the terminal device 100. After integration, it can be simply referred to as a touch display screen. In the present invention, the display unit 130 can display application programs and corresponding operation steps.
[0040] The camera 140 can be used to capture still images or videos. An object generates an optical image through a lens and projects it onto a photosensitive element. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the processor 180 to be converted into a digital image signal.
[0041] The terminal device 100 may further include at least one sensor 150, such as an acceleration sensor 151, a distance sensor 152, a fingerprint sensor 153, and a temperature sensor 154. The terminal device 100 may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, a light sensor, and a motion sensor.
[0042] The audio circuit 160, the speaker 161, and the microphone 162 may provide an audio interface between the user and the terminal device 100. The audio circuit 160 may transmit the electrical signal converted from the received audio data to the speaker 161, and the speaker 161 converts it into a sound signal for output. The terminal device 100 may also be configured with volume buttons for adjusting the volume of the sound signal. On the other hand, the microphone 162 converts the collected sound signal into an electrical signal, which is received by the audio circuit 160 and then converted into audio data. The audio data is then output to the RF circuit 110 for transmission to another terminal, for example, or output to the memory 120 for further processing. In the present invention, the microphone 162 can acquire the user's voice.
[0043] Wi-Fi belongs to short-range wireless transmission technology. The terminal device 100 can help the user send and receive emails, browse the web, and access streaming media through the Wi-Fi module 170, which provides the user with wireless broadband Internet access.
[0044] The processor 180 is the control center of the terminal device 100, connecting various parts of the entire terminal through various interfaces and lines. By running or executing the software programs stored in the memory 120 and calling the data stored in the memory 120, the processor 180 performs various functions of the terminal device 100 and processes data. In some embodiments, the processor 180 may include one or more processing units; the processor 180 may also integrate an application processor and a baseband processor. Among them, the application processor mainly processes the operating system, user interface, and application programs, etc., and the baseband processor mainly processes wireless communication. It can be understood that the above baseband processor may not be integrated into the processor 180. In the present invention, the processor 180 can run the operating system, application programs, user interface display, and touch response, as well as the processing method described in the embodiments of the present invention. In addition, the processor 180 is coupled to the display unit 130 and the camera 140.
[0045] The Bluetooth module 181 is used to interact with other Bluetooth devices having a Bluetooth module through the Bluetooth protocol. For example, the terminal device 100 can establish a Bluetooth connection with a wearable electronic device (such as a smart watch) that also has a Bluetooth module through the Bluetooth module 181, so as to perform data interaction.
[0046] The terminal device 100 further includes a power source 190 (such as a battery) for powering each component. The power source can be logically connected to the processor 180 through a power management system, so as to manage functions such as charging, discharging, and power consumption through the power management system. The terminal device 100 can also be configured with a power button for functions such as turning on and off the terminal and locking the screen.
[0047] Figure 2 It is a software structure block diagram of the terminal device 100 according to an embodiment of the present invention.
[0048] The layered architecture divides the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom, namely the application layer, the application framework layer, the Android runtime, the system libraries, and the kernel layer.
[0049] The application layer may include a series of application packages.
[0050] As Figure 2 shown, the application packages may include applications such as a camera, a gallery, a calendar, a call, a map, a navigation, a WLAN, a Bluetooth, music, a video, a short message, etc.
[0051] The application framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined functions.
[0052] As Figure 2 shown, the application framework layer may include a window manager, a content provider, a view system, a telephone manager, a resource manager, a notification manager, etc.
[0053] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.
[0054] The content provider is used to store and obtain data, and make this data accessible to applications. The data may include videos, images, audio, dialed and answered calls, browsing history and bookmarks, phone books, etc.
[0055] The view system includes visible controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build applications. The display interface can be composed of one or more views. For example, a display interface including a short message notification icon may include a view for displaying text and a view for displaying pictures.
[0056] The telephone manager is used to provide the communication function of the terminal device 100. For example, the management of call status (including connection, disconnection, etc.).
[0057] The resource manager provides various resources for applications, such as localized strings, icons, pictures, layout files, video files, and so on.
[0058] The notification manager enables applications to display notification information in the status bar. It can be used to convey message types that need to be informed, and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to inform that the download is completed, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as the notification of a background running application, and can also be a notification that appears on the screen in the form of a dialogue window. For example, it prompts text information in the status bar, emits a prompt sound, the terminal device vibrates, the indicator light flashes, etc.
[0059] The Android Runtime includes the core libraries and the virtual machine, and the Android Runtime is responsible for the scheduling and management of the Android system.
[0060] The core libraries include two parts: one part is the functional functions that need to be called by the Java language, and the other part is the core libraries of Android.
[0061] The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as the management of object life cycles, stack management, thread management, security and exception management, and garbage collection.
[0062] The system libraries can include multiple functional modules. For example: surface manager, Media Libraries, 3D graphics processing library (such as: OpenGL ES), 2D graphics engine (such as: SGL), etc.
[0063] The surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.
[0064] The media library supports the playback and recording of multiple common audio and video formats, as well as static image files, etc. The media library can support multiple audio and video coding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.
[0065] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc.
[0066] The 2D graphics engine is the graphics engine for 2D drawing.
[0067] The kernel layer is the layer between hardware and software. The kernel layer includes at least a display driver, a camera driver, an audio driver, and a sensor driver.
[0068] The following takes the capture and photo-taking scenario as an example to exemplarily illustrate the working processes of the software and hardware of the terminal device 100.
[0069] When the touch screen 131 receives a touch operation, the corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including information such as touch coordinates and the time stamp of the touch operation). The raw input event is stored in the kernel layer. The application framework layer obtains the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking the touch operation as a touch click operation and the control corresponding to the click operation as the control of the camera application icon as an example, the camera application calls the interface of the application framework layer to start the camera application, and then starts the camera driver by calling the kernel layer, and captures a static image or video through the camera 140.
[0070] The terminal device 100 in the embodiments of the present invention may be a mobile phone, a tablet computer, a wearable device, a notebook computer, a television, etc.
[0071] The applicant found in the research that for a specific scenario with regulations, in order to avoid program confusion in an asynchronous environment, the current solution is to delay the operation. The specific process includes:
[0072] First, conduct an evaluation test, and count the interval time from when the camera is turned on to when the camera is successfully started. After operating many times, obtain a longest time (represented by t);
[0073] After that, when the camera is turned on, start timing, and perform camera preview at a moment when the time is greater than t, then normal operation can be carried out to avoid abnormalities of the camera.
[0074] The disadvantage of this solution is that although the delay time is greater than t, seemingly sufficient time, in other situations (such as when the resources of the device are all used to handle other situations at this time), this delay time may be insufficient and lead to abnormalities.
[0075] Moreover, for the delay time, even after multiple tests, all special situations cannot be avoided, and the delay time cannot be too long.
[0076] Therefore, the embodiments of the present invention provide a multi-thread control method to avoid program confusion in an asynchronous environment.
[0077] Specifically, a multi-thread control method provided by the embodiments of the present invention, as Figure 3 shown, may include:
[0078] S301: If a target operation needs to be performed on a device in a first thread, the first thread is controlled to be in a blocked state, and a state flag of a shared lock is set to an initial value in the first thread;
[0079] Among them, controlling the first thread to be in a blocked state can be understood as:
[0080] The first thread is locked so that subsequent operations cannot be performed on the first thread.
[0081] Furthermore, if the multi-thread control method is applied to a camera processing scenario, the device may be a camera, and the target operation may be camera opening or camera preview.
[0082] Of course, in the embodiment of the present invention, the application scenario is not limited to the camera processing scenario, and can also be applied to other asynchronous thread synchronous processing scenarios, which is not limited here.
[0083] S302: Execute a program for implementing the target operation in the second thread. If the result obtained after the execution is successful, set the state flag of the shared lock to the target value in the second thread;
[0084] S303: When it is determined in the first thread that the state mark of the shared lock is the target value, wake up the first thread.
[0085] That is, when it is determined that the state mark of the shared lock is the target value, it can be determined that the target operation is successfully executed.
[0086] Among them, waking up the first thread can be understood as:
[0087] Unlock the first thread and release the blocking state of the first thread, so that subsequent operations can be executed in the first thread.
[0088] In this way, if it is necessary to perform a target operation on the device in the first thread, the first thread can be controlled to be in a blocked state so that the first thread will not continue to execute subsequent operations; at this time, the program for implementing the target operation can be executed in the second thread, and the status mark of the shared lock can be set in the second thread according to the execution result; further, it can be determined whether the first operation is successfully executed based on the status mark of the shared lock. If the execution is successful, the first thread can be awakened again, the blocking state of the first thread is released, and the subsequent operations can be continued in the first thread; at this time, when executing subsequent operations in the first thread, since the previous target operation is executed successfully, the subsequent operations can be carried out normally, and no abnormal phenomena will occur, thereby avoiding adverse effects on subsequent operations, thereby realizing the sequential execution of operations of different threads under the same thread in an asynchronous environment, avoiding abnormalities caused by asynchronous operations in an asynchronous environment.
[0089] In some embodiments, it also includes:
[0090] After controlling the first thread to be in a blocked state, in the first thread, poll the status flag of the shared lock;
[0091] When it is determined that the status flag of the shared lock is the target value, end the polling.
[0092] In this way, through polling, the status flag of the shared lock can be determined in a timely and effective manner, and then it can be determined in a timely and effective manner whether the target operation is executed successfully, which is convenient for executing subsequent operations in a timely and effective manner, ensuring the real-time nature of the operation execution and improving the user experience.
[0093] In some embodiments, in the first thread, polling the status flag of the shared lock specifically includes:
[0094] When a polling sub-thread is created in the first thread, in the polling sub-thread, poll the status flag of the shared lock.
[0095] In this way, through the polling sub-thread, the status flag of the shared lock can be determined in a timely and effective manner, ensuring the real-time nature of the operation execution and improving the user experience.
[0096] In some embodiments, it further includes:
[0097] If the result obtained after execution is a failure, keep the status flag of the shared lock unchanged.
[0098] Among them, the initial value can be 0, and the target value can be 1; or, the initial value can be 1, and the target value can be 0.
[0099] Of course, the initial value and the target value are not limited to 0 and 1, and can also be one or more combinations of other characters, numbers, special symbols, and letters that can achieve the marking function, which can be specifically set according to actual needs and is not limited here.
[0100] In this way, when the execution fails, the status flag of the shared lock can be kept unchanged. Thus, during polling, if it is determined that the status flag of the shared lock has always been the initial value, it can be considered that the execution fails, and then there is no need to wake up the first thread to avoid exceptions when waking up the first thread at this time.
[0101] It should be emphasized that in the embodiments of the present invention, when controlling the first thread to be in a blocked state, set the status flag of the shared lock to the target value in the first thread; subsequently, when setting the status flag of the shared lock according to the execution result, if the execution is successful, it can be adjusted to the target value, and if the execution fails, the status flag can be kept unchanged, so as to more clearly determine whether the target operation is successfully executed according to the status flag.
[0102] In some embodiments, in the first thread, setting the status flag of the shared lock to the initial value specifically includes:
[0103] In the first thread, acquire the shared lock and determine whether the acquisition is successful;
[0104] If so, in the first thread, set the status flag of the shared lock to the initial value and release the shared lock when the setting is completed;
[0105] If not, control the first thread to join the preset queue and occupy the position with the smallest sorting number among the unoccupied positions in the preset queue. When the first thread is at the head of the preset queue, in the first thread, acquire the shared lock again until the acquisition is successful;
[0106] Among them, when the thread at the head of the queue acquires the shared lock again, control the thread to break away from the preset queue, and control the sorting numbers of the remaining threads in the preset queue to decrease by one in turn; the sorting numbers of each position in the preset queue are positively correlated with the joining order.
[0107] That is to say, when joining the preset queue, the earlier one joins, the smaller the sorting number of the position in the preset queue; the later one joins, the larger the sorting number of the position in the preset queue.
[0108] In this way, by setting the status flag of the shared lock in the above manner, when the acquisition of the shared lock fails, it can be cyclically acquired according to the conditions until the acquisition is successful, which can effectively set the status flag of the shared lock. Thus, based on the status flag of the shared lock, it can be determined whether the target operation is successfully completed, and the operations of different threads can be sequentially executed in the same thread in an asynchronous environment.
[0109] In some embodiments, in the second thread, setting the status flag of the shared lock to the target value specifically includes:
[0110] In the second thread, acquire the shared lock and determine whether the acquisition is successful;
[0111] If so, in the second thread, set the status flag of the shared lock to the target value and release the shared lock when the setting is completed;
[0112] If not, control the second thread to join the preset queue and occupy the position with the smallest sorting number among the unoccupied positions in the preset queue. When the second thread is at the head of the preset queue, in the second thread, acquire the shared lock again until the acquisition is successful;
[0113] Among them, when the thread at the head of the queue acquires the shared lock again, control the thread to break away from the preset queue, and control the sorting numbers of the remaining threads in the preset queue to decrease by one in turn; the sorting numbers of each position in the preset queue are positively correlated with the joining order.
[0114] That is to say, if the process of setting the status flag of the shared lock in the first thread (denoted as process 1) and the process of setting the status flag of the shared lock in the second thread (denoted as process 2) described above are considered, then process 2 is basically similar to process 1.
[0115] In some embodiments, it further includes:
[0116] Before acquiring the shared lock again, it is determined that the shared lock is in an idle state.
[0117] Among them, the shared lock being in an idle state can be understood as:
[0118] The state where no thread acquires the shared lock.
[0119] In this way, acquiring when the shared lock is in an idle state can increase the probability of successful acquisition, improve the efficiency of setting the status flag of the shared lock, thereby improving the execution efficiency of two adjacent operations under the same thread and enhancing the user experience.
[0120] It should be noted that in specific implementation, if the first thread and the second thread mentioned above are regarded as a thread group, there can be at least one such thread group; especially when there are multiple such thread groups, there may be a situation where multiple threads acquire the shared lock simultaneously. Taking three threads acquiring the shared lock simultaneously as an example, then:
[0121] When these three threads acquire the shared lock simultaneously, one of the threads may acquire it successfully, while the other two threads will acquire it fail.
[0122] Therefore, the two threads that fail to acquire need to be added to a preset queue to wait. When either of the two threads is at the head of the preset queue and the shared lock is in an idle state, they can attempt to acquire the shared lock again to increase the probability of successful acquisition.
[0123] Moreover, the above content is only described based on one target operation. In actual situations, in the first thread, multiple target operations may need to be executed. That is, after executing the first target operation, the second target operation also needs to be executed. For example, camera opening and camera preview. At this time, for any target operation, it can be executed according to the above embodiments.
[0124] Next, the above multi-thread control method provided by the embodiments of the present invention will be described in conjunction with specific embodiments.
[0125] Embodiment: In combination with Figure 4 As shown, taking camera opening and camera preview, with an initial value of 1 and a target value of 0 as an example for description.
[0126] S401. When it is necessary to open the camera in the first thread, set the status flag of the shared lock to 1 in the first thread and block the first thread; in the polling child thread, poll the status flag of the shared lock.
[0127] The shared lock is a global lock, and each thread can set the shared lock.
[0128] Moreover, blocking the first thread means controlling the first thread to be in a blocked state.
[0129] S402. In the second thread, execute the specific camera opening program and determine whether the camera is successfully opened according to the callback; if it is successfully opened, set the status flag of the shared lock to 0 in the second thread and execute S403; if it is not successfully opened, keep the status flag of the shared lock as 1 in the second thread, notify the user that the opening failed, and end the process.
[0130] The status flag of the shared lock being 0 can indicate that the first thread can continue to execute the next operation, such as camera preview.
[0131] Moreover, if it is not successfully opened, it may be that there is a problem with the camera. Therefore, at this time, the camera opening process cannot be continued, but the process needs to be exited to check the camera.
[0132] S403. If it is determined through polling that the current status flag of the shared lock is 0, it is determined that the camera is successfully opened, the first thread is awakened, and the polling is ended simultaneously.
[0133] The polling child thread can be a child thread created within the first thread.
[0134] S404. When it is necessary to perform camera preview in the first thread, set the status flag of the shared lock to 1 in the first thread and block the first thread; in the polling child thread, poll the status flag of the shared lock.
[0135] S405. In the third thread, execute the specific camera preview program and determine whether the camera is successfully previewed according to the callback; if it is successfully previewed, set the status flag of the shared lock to 0 in the third thread and execute S406; if it is not successfully previewed, keep the status flag of the shared lock as 1 in the third thread, notify the user that the preview failed, and end the process.
[0136] If it is not successfully previewed, it may be that there is a problem with the camera. Therefore, at this time, the camera preview process cannot be continued, but the process needs to be exited to check the camera.
[0137] S406. If it is determined through polling that the current status flag of the shared lock is 0, it is determined that the camera is successfully previewed, the first thread is awakened, and the polling is ended simultaneously.
[0138] S407. Receive the image data fed back by the third thread in the first thread, and perform image processing on the image data.
[0139] Based on the above process, actual test analysis was conducted, and the following conclusions can be obtained based on the test results:
[0140] Adopt the process given in the above embodiment to execute camera opening and camera preview, and use it as the test group; adopt the way of delaying operation in the prior art to execute camera opening and camera preview, and use it as the control group;
[0141] Among them, in the control group, if the delay is 2 seconds, the probability of successfully executing the entire operation (that is, the operation including camera opening and camera preview) is only 60%. If the delay is 4 seconds, the success probability is 90%. Although the success probability is relatively high when the delay is 4 seconds, the 4 - second delay is too long, which will cause the user to stay in the black background interface for 3 seconds when opening the camera, and users can basically not accept this situation (the reason why users feel that the time is shorter than the delay time is mainly because the time for initializing the background is not calculated by the user).
[0142] While in the test group, the operations of camera opening and camera preview can be processed within 2 seconds, and in extreme cases, it can be completed in less than 1 second. Obviously, the processing speed has been greatly improved compared with the control group.
[0143] Embodiment: Combine Figure 5 As shown, for the process of setting the status flag of the shared lock; and the following process can be applied to any one thread. This embodiment is described by taking the first thread as an example.
[0144] S501. In the first thread, obtain the shared lock and determine whether the acquisition is successful; if so, set the status flag of the shared lock to the initial value in the first thread, and then execute S503; if not, control the first thread to join the preset queue and occupy the position with the smallest sorting number among the unoccupied positions in the preset queue, and execute S502;
[0145] It should be noted that in the embodiment of the present invention, and not limited to this embodiment, it is applicable to the situation where multiple threads operate on the shared lock simultaneously, and is also applicable to the situation where only one thread operates on the shared lock at the same time.
[0146] S502. When the first thread in the preset queue is at the head of the queue, determine whether the shared lock is currently in the idle state; if so, return to S501; if not, wait until it is in the idle state, that is, continue to execute this step;
[0147] Among them, there may be multiple threads in the preset queue. When the thread at the head of the queue (assumed to be the first thread) attempts to acquire the shared lock again, the threads behind the head of the queue are in the waiting stage. When the first thread attempts to acquire the lock again, the first thread needs to be detached from the preset queue, and at the same time, the sorting sequence numbers of the positions where the subsequent threads are located need to move forward one by one in sequence, so that the thread originally ranked second moves to the head of the queue, the thread originally ranked third moves to the second place, and so on.
[0148] For example, taking the case where there are three threads in the preset queue as an example, the three threads are respectively labeled as thread A, thread B, and thread C. Assume that thread A is at the head of the queue because it joined the preset queue first, thread B joined the preset queue second so it is ranked second, and thread C joined the preset queue third so it is ranked third. Then:
[0149] When thread A acquires the shared lock, it detaches from the preset queue. At the same time, thread B moves to the head of the queue, and thread C moves to the second place;
[0150] If thread A fails to acquire the lock, it needs to continue to join the preset queue and be ranked third.
[0151] For thread B and thread C, the situation is similar to that of thread A, and will not be elaborated again here.
[0152] S503. Release the shared lock in the first thread.
[0153] Among them, after the release is successful, there are the following several possibilities:
[0154] The first thread leaves the preset queue (for the case where the first thread has joined the preset queue before);
[0155] Or, the first thread rejoins the preset queue and is ranked at the position with the smallest sorting sequence number among the unoccupied positions in the preset queue;
[0156] Or, the first thread remains outside the preset queue (for the case where the first thread has never joined the preset queue).
[0157] And, when releasing the shared lock, if the release is not successful, it can continue to be released until the release is successful.
[0158] Based on the same inventive concept, an embodiment of the present invention provides a multi-thread control device. The implementation principle of this device is similar to that of the foregoing multi-thread control method. The specific implementation manner of this device can refer to the specific embodiments of the foregoing method, and the repeated parts will not be elaborated again.
[0159] Specifically, a multi-thread control device provided by an embodiment of the present invention, as Figure 6 shown, may include:
[0160] A memory 601 for storing program instructions;
[0161] A processor 602 for invoking the program instructions stored in the memory 601 and executing the above multi-thread control method provided in the embodiments of the present invention according to the obtained program.
[0162] Based on the same inventive concept, an embodiment of the present invention provides a readable storage medium storing multi-thread control device executable instructions for causing a multi-thread control device to execute the above multi-thread control method provided in the embodiments of the present invention.
[0163] Based on the same inventive concept, an embodiment of the present invention provides a terminal device including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the steps of the above multi-thread control method provided in the embodiments of the present invention when executing the program.
[0164] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.
Claims
1. A multi-thread control method, characterized in that, Including: When it is necessary to perform a target operation on a device in a first thread, control the first thread to be in a blocked state, and in the first thread, set the status flag of the shared lock to the initial value; Execute a program for implementing the target operation in a second thread. If the result obtained after execution is successful, in the second thread, set the status flag of the shared lock to the target value; When it is determined in the first thread that the status flag of the shared lock is the target value, wake up the first thread; In the first thread, setting the status flag of the shared lock to the initial value specifically includes: In the first thread, acquire the shared lock and determine whether the acquisition is successful; If so, in the first thread, set the status flag of the shared lock to the initial value, and release the shared lock when the setting is completed; If not, control the first thread to join a preset queue and occupy the position with the smallest sorting serial number among the unoccupied positions in the preset queue. When the first thread is at the head of the preset queue, in the first thread, acquire the shared lock again until the acquisition is successful; Wherein, when the thread at the head of the queue acquires the shared lock again, control the thread to break away from the preset queue, and control the sorting serial numbers of the remaining threads in the preset queue to decrease by one in turn; the sorting serial numbers of the positions in the preset queue are positively correlated with the joining order; In the second thread, setting the status flag of the shared lock to the target value specifically includes: In the second thread, acquire the shared lock and determine whether the acquisition is successful; If so, in the second thread, set the status flag of the shared lock to the target value, and release the shared lock when the setting is completed; If not, control the second thread to join a preset queue and occupy the position with the smallest sorting serial number among the unoccupied positions in the preset queue. When the second thread is at the head of the preset queue, in the second thread, acquire the shared lock again until the acquisition is successful; Wherein, when the thread at the head of the queue acquires the shared lock again, control the thread to break away from the preset queue, and control the sorting serial numbers of the remaining threads in the preset queue to decrease by one in turn; the sorting serial numbers of the positions in the preset queue are positively correlated with the joining order.
2. The method according to claim 1, wherein Further including: If the result obtained after execution is a failure, keep the status flag of the shared lock unchanged.
3. The method according to claim 1, wherein Further including: Before acquiring the shared lock again, determine that the shared lock is in an idle state.
4. The method according to claim 1, characterized in that, Further including: After controlling the first thread to be in the blocked state, in the first thread, poll the status flag of the shared lock; When it is determined that the status flag of the shared lock is the target value, end the polling.
5. The method according to claim 4, wherein In the first thread, polling the status flag of the shared lock specifically includes: When a polling sub-thread is created in the first thread, in the polling sub-thread, poll the status flag of the shared lock.
6. A multi-thread control device, characterized in that, Including: A memory for storing program instructions; A processor for calling the program instructions stored in the memory and executing the multi-thread control method according to any one of claims 1-5 according to the obtained program.
7. A readable storage medium, characterized in that, The readable storage medium stores multi-thread control device executable instructions for causing the multi-thread control device to execute the multi-thread control method according to any one of claims 1-5.
8. A terminal device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, the steps of the multi-thread control method according to any one of claims 1-5 are implemented.
Citation Information
Patent Citations
Task execution method and device
CN110688203A
Resource access method and device, electronic equipment and computer readable storage medium
CN112764941A
Shared User-Mode Locks
US20090328041A1