CN115269149A - Method and system for multi-window task scheduling mechanism based on shared memory - Google Patents

Method and system for multi-window task scheduling mechanism based on shared memory Download PDF

Info

Publication number
CN115269149A
CN115269149A CN202210914900.1A CN202210914900A CN115269149A CN 115269149 A CN115269149 A CN 115269149A CN 202210914900 A CN202210914900 A CN 202210914900A CN 115269149 A CN115269149 A CN 115269149A
Authority
CN
China
Prior art keywords
window
shared memory
task
thread
setting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210914900.1A
Other languages
Chinese (zh)
Inventor
喻洪乾
孟祥锐
韩雨
陈子光
袁泳佳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Ylink Computing System Co ltd
Original Assignee
Shenzhen Ylink Computing System Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Ylink Computing System Co ltd filed Critical Shenzhen Ylink Computing System Co ltd
Priority to CN202210914900.1A priority Critical patent/CN115269149A/en
Publication of CN115269149A publication Critical patent/CN115269149A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/544Buffers; Shared memory; Pipes

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention discloses a method and a system for a multi-window task scheduling mechanism based on a shared memory, wherein the method comprises the following steps: setting the upper limit of the number of task windows and the state of the task windows; setting the processing priority of a task window by a thread scheduling method; and dynamically adjusting the state of the task window through a window operation method. The invention realizes the improvement of the operating efficiency of the multi-window data entry personnel by setting a thread scheduling mechanism and a multi-window operating mechanism according to the priority; the associated cost and labor cost of the data entry equipment are saved.

Description

Method and system for multi-window task scheduling mechanism based on shared memory
Technical Field
The invention relates to the technical field of computers, in particular to a method and a system for a multi-window task scheduling mechanism based on a shared memory.
Background
In order to enter more tasks, a data entry clerk often obtains tasks to be entered simultaneously from different systems, and therefore a plurality of different Windows need to be opened to receive data entry tasks from the systems. This situation has the following disadvantages:
(1) The input personnel needs to continuously and actively check each window to determine whether the task to be input is received, which is time-consuming and labor-consuming;
(2) After a certain window receives an input task, an input worker manually switches the window to the topmost layer of the desktop through a keyboard or a mouse to input data; the operation is time-consuming and the efficiency is low;
(3) The order of the windows is switched manually, not necessarily in accordance with the order of the task queue. Some tasks to be entered will be timed out.
Disclosure of Invention
The invention discloses a method and a device for a multi-window task scheduling mechanism based on a shared memory, which comprises the following steps:
setting the upper limit of the number of task windows and the state of the task windows;
setting the processing priority of a task window by a thread scheduling method;
and dynamically adjusting the state of the task window through a window operation method.
Further, the number of the task windows is 1-10.
Preferably, the state of the task window includes: idle, queued, and in-job.
Further, the thread scheduling method comprises the following steps;
creating a shared memory space through a memory allocation function;
starting a scheduling thread through a thread function;
and circularly checking the queuing time of each task window in the shared memory until the thread is finished, and setting the window with the longest queuing time as the operation.
The memory allocation function is expressed by formula 1 as follows:
CreateFileMapping<hFile><lpSecAttr><dwProtect><maxSizeHi><max SizeLo><lpName>
OpenFileMapping<dwAccess><isInherit><lpName>
MapViewOfFile<hMapFile><dwAccess><dwOffsetHi><dwOffsetLo><dwMapBytes> (1)
the shared memory block is created by createFileMapping, hFile represents a physical file handle, lpSecAtttr represents security setting, dwProtect represents read-write protection setting, maxSizeHi represents the high-order 4 bytes of the size of a shared memory, maxSizeLo represents the low-order 4 bytes of the size of the shared memory, and lpName represents the name of the shared memory; returning the shared memory handle;
OpenFileMapping represents opening the shared memory, dwAccess represents read-write protection setting, isinheri represents whether the returned shared memory handle can be inherited, and lpName represents the name of the shared memory to be opened; returning a shared memory handle;
MapViewOfFile indicates mapping the shared memory to the current process, hMapFile is a handle returned for creating or opening the shared memory, dwAccess indicates read-write protection setting, dwOffsetHi indicates mapping the upper 4 bytes of the start position of the shared memory, dwOffsetLo indicates mapping the lower 4 bytes of the start position of the shared memory, dwMapBytes indicates the number of direct numbers to be mapped: and when the value is 0, the whole shared memory is mapped.
Wherein, the thread function is expressed by formula 2:
_beginthread<fpFunc><dwStackSize><lpArgs> (2)
where _ begin represents the thread started, fpFunc represents the thread execution function, dwStackSize represents the stack size of the new thread, lpArgs represents the parameters passed to the thread.
Further, the window working method includes the steps of:
registering a current task window to a shared memory;
setting the state of a current task window as idle;
and circularly checking whether the task is received until the thread is finished, and if the task is received, setting the state of the task window into a queue and recording the queue starting time.
On the other hand, the invention adopts another technical scheme that: a document generation system and a storage medium are provided, the system comprising:
a global module: the method comprises the steps of setting an upper limit of the number of task windows and the state of the task windows;
a thread scheduling module: the priority level of the task window is set;
a window operation module: for dynamically adjusting the state of the task window.
Further, the system further comprises a shared memory management device, wherein the shared memory management device runs in a Linux operating system, and the Linux operating system comprises a shmget shared memory management interface.
Preferably, the shmvet shared memory management interface is used for being called by an application program to set the read-write operation attribute of the application program to the cache.
Further, the present invention also includes a client, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the method when executing the computer program;
still further, the present invention also includes a computer-readable storage medium storing a computer program and being applied to a client, the computer program implementing the steps of the above method when being executed by a processor.
Compared with the prior art, the invention has at least the following advantages and positive effects:
1. after automatic scheduling is added, the operation efficiency of multi-window data input personnel can be greatly improved;
2. the purchase and use cost of the data entry equipment is saved due to the improvement of the operation efficiency of the single equipment;
3. because the operating efficiency of the single equipment is improved, the number of data entry personnel is reduced, and the labor cost is saved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without inventive efforts, wherein:
fig. 1 is a flowchart illustrating a method for a shared-memory-based multi-window task scheduling mechanism according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating a thread scheduling method according to another embodiment of the present invention;
FIG. 3 is a flowchart illustrating a window operating method according to another embodiment of the present invention;
fig. 4 is a schematic structural diagram of a system for a multi-window task scheduling mechanism based on a shared memory according to another embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.
Example one
Fig. 1 is a flowchart illustrating a method for a multi-window task scheduling mechanism based on a shared memory according to an embodiment of the present invention. The method comprises the following steps:
s1: setting the upper limit of the number of task windows and the state of the task windows;
s2: setting the processing priority of a task window by a thread scheduling method;
s3: dynamically adjusting the state of a task window through a window operation method;
the API, i.e. the application program interface function, is some predefined function. The operating system is a large service center besides coordinating the execution of the application program, memory allocation and system resource management, and calls various services (each service is a function) of the service center to help the application program achieve the purposes of opening a window, drawing a graph and using peripheral equipment.
The application program interface is: the "computer operating system" or "library" provides the code used by the application calls. The main purpose is to allow application developers to invoke a set of routine functions without regard to the underlying source code or understanding the details of its internal working mechanisms. The API itself is abstract and defines only one interface, and does not involve the concrete operation of the application program in the actual implementation process.
For example, a set of APIs in a graphics library define the way pointers are drawn, which can be displayed on a graphical output device. When an application requires pointer functionality, it can be linked to this set of APIs at reference, compile time, and the runtime will call the implementation (library) of this API to display the pointer.
An api is a set of thousands of extremely complex functions and subroutines that allow a programmer to perform many tasks, such as "reading a file," "displaying a menu," "displaying a web page in a window," and so forth. The operating system's APIs may be used to allocate memory or read files. Many system applications are implemented via API interfaces, such as graphics systems, databases, web services, and even online games.
There are many different designs for application program interfaces. Interfaces for fast execution typically include functions, constants, variables, and data structures. There are other ways to ensure that code using an API does not need to be modified to accommodate implementation changes, such as through an interpreter or providing an abstraction layer to mask information associated with the API implementation.
Application program interfaces are often part of a Software Development Kit (SDK).
A software development kit is a collection of development tools used by software engineers to create application software for a particular software package, software framework, hardware platform, operating system, etc., and in general, an SDK is an SDK used to develop applications under a Windows platform. It may simply be a file that provides an application program interface API for a certain programming language, but may also include complex hardware that can communicate with a certain embedded system. Typical tools include utility tools for debugging and other purposes. SDKs also often include example code, supporting technical notes, or other supporting documentation to clarify suspicions for basic reference.
The API function is contained in a dynamic link library file under the Windows system directory.
The Windows api is a set of predefined Windows functions that are used to control the appearance and behavior of the various components of Windows. Each action by the user causes one or several functions to run to tell Windows what is happening. This is somewhat much like Windows' native code. While others simply provide a way to access the API automatically and more easily. When you click a button on the form, windows will send a message to the form, and VB takes this call and generates a specific event after analysis.
The Windows system is a large service center besides coordinating the execution of application programs, the allocation of memory, and the management of system resources. Calling various services (each service is a function) of the service center can help an application program to achieve the purposes of opening a window, drawing a graph, using peripheral equipment and the like. The WIN32API is also the application programming interface of the Microsoft Windows 32-bit platform. All application programs executed under the Windows working environment can call the Windows API.
Example two
Fig. 2 is a schematic flowchart of a thread scheduling method according to another embodiment of the present invention, including the following steps:
s20: creating a shared memory space through a memory allocation function;
s21: starting a scheduling thread through a thread function;
s23: and circularly checking the queuing time of each task window in the shared memory until the thread is finished, and setting the window with the longest queuing time as the operation.
A thread is the smallest unit that an operating system can perform computational scheduling. It is included in the process and is the actual unit of operation in the process. A thread refers to a single sequential control flow in a process, multiple threads can be concurrently executed in a process, and each thread executes different tasks in parallel. UnixSystemV and SunOS are also referred to as lightweight processes, but lightweight processes are more referred to as kernel threads and user threads are referred to as threads.
Threads are the basic unit of independent scheduling and dispatching. The thread may be a kernel thread scheduled by an operating system kernel, such as a Win32 thread; a user thread which is self-scheduled by a user process, such as POSIXThread of a Linux platform; or by the kernel in a mixed schedule with user processes, such as Windows7 threads.
Multiple threads in the same process will share all system resources in the process, such as virtual address space, file descriptors, signal processing, etc. But multiple threads in the same process have respective call stacks, respective register contexts, and respective thread local stores.
A process may have many threads, each executing a different task in parallel. The benefit of using multi-thread programming on multi-core or multi-CPU, or Hyper-threading enabled CPUs is apparent, namely, the execution throughput of the program is improved. On a computer with a single CPU and a single core, a multithreading technology is used, a part which is in charge of I/O processing and man-machine interaction and is often blocked in a process can be separated from a part for intensive calculation to be executed, a workhorse thread is written to execute the intensive calculation, and therefore the execution efficiency of a program is improved.
As with the other two IPC mechanisms, before using the shared memory region, a process must create a key-keyed shared memory object by using the system call sys _ IPC (call value is shmfet), or obtain a reference identifier of an existing key-keyed shared memory object. Subsequent accesses to the shared memory object are made via the reference identifier. The creation or acquisition of the shared memory object is accomplished by the function sys _ shmlet, which is defined as follows: intsys _ shmget (key _ tkey, intsize, intshmflg, where key is a key representing the shared memory object, size is the size of the shared memory region (in bytes), shmflg is a flag, if key = = IPC _ prior, a new shared memory object is always created.
EXAMPLE III
Fig. 3 is a schematic flowchart of a window operating method according to another embodiment of the present invention, including the following steps:
s30: registering a current task window to a shared memory;
s31: setting the state of a current task window to be idle;
s32: and circularly checking whether the task is received until the thread is finished, and if the task is received, setting the state of the task window into a queue and recording the queue starting time.
Shared memory is a method for implementing interprocess communication (IPC), and different processes implement data sharing and interaction by accessing the same memory area in the same block. Each process can map its own virtual address to a specific region in the physical memory, and when different processes associate the same physical memory region with their respective virtual address spaces, the processes can implement IPC by sharing the memory. If a process changes the contents of the shared memory area, other processes will perceive the change in the area.
Each process has its own process control block and address space, and has a page table corresponding to it, which is responsible for mapping the virtual address and physical address of the process, and managing them through a Memory Management Unit (MMU). Two different virtual addresses are mapped to the same region of physical space through a page table, and the region of the physical space to which the two different virtual addresses point is shared memory.
But shared memory has no interprocess synchronization and mutual exclusion mechanism. For example, process a performs a write operation to the shared memory, and before the write operation of a is completed, process B can read data from the shared memory area, and there is no automatic mechanism to prevent the read operation of process B. In general, in order to implement process synchronization and mutual exclusion, a shared memory and a semaphore are often used together.
windows is a message driven system, and windows' messages provide a means for communicating between applications and between an application and the windows system. The functions that the application wants to implement are triggered by the message and are done by responding to and processing the message. It must be noted that messages are not preemptive, and are always processed in order of arrival, regardless of the urgency of the event. The disadvantage is that some real-time external events may not be handled in a timely manner.
windows visualization interaction is typically implemented through windows. A window is typically created within a thread. The windows system manages interaction through a message mechanism, messages are sent, stored and processed, and one thread can maintain a set of message queues of the thread so as to keep the exclusivity among the threads. The queue is characterized by first-in first-out, which may implement an asynchronous demand response process.
The message may be generated by a system or an application. The system generates a message when an input event occurs (user hits keyboard, moves mouse). The system may also generate messages in response to changes made by the application (setting system fonts). While the application may generate messages to cause the forms to perform tasks or to communicate with other applications.
From the windows maintenance perspective, there are two types of message queues: the device driver converts the operation input into a message stored in the system queue, and then the system puts the message into a thread message queue where the target window is located to wait for processing.
And secondly, a thread message queue is maintained by each GUI thread, the queue is created only when the thread calls the GDI function, and is not created by default, so that the message queue is not created for the Non-GUI thread when all threads are generated, and the system creates a message queue for the thread only when the thread calls the GDI function for the first time. The messages in the thread message queue are then sent to the corresponding window process for processing.
Example four
Fig. 4 is a schematic structural diagram of a system for a shared-memory-based multi-window task scheduling mechanism according to another embodiment of the present invention. The system comprises a global module 100, a thread scheduling module 200, a window operation module 300 and a shared memory management device 400. The global module 100 is configured to set an upper limit of the number of task windows and a state of the task windows; the thread scheduling module 200 is configured to set a priority of the task window; the window operation module 300 is used for dynamically adjusting the state of the task window; shared memory management device 400 operates in a Linux operating system that includes a shmget shared memory management interface that is used by applications to call to set read and write operation attributes of the applications to a cache.
Each Win32 program has a WinMain function, which corresponds to the main function of the console program. Although it is not the first function that the program is called. After entering WinMain function, the program needs to call register class, which should be the attribute of name, type, size, etc. of the window to tell the system, and is the class describing Win32 program, and the displayed window is just an example of this class. Registering a window entails providing a pointer to the "window function" to the system, and since Windows programs are message and event driven, the system must be told who handled the message for that type of window. After the window class is successfully registered, the CreateWindow and ShowWindow functions need to be called to create and display the window. When a window is created, the system sends a WM _ CREATE message to the window, so that the program has the opportunity to do some initialization operation after the window is successfully created. When a window is displayed, the system will also send a WM _ PAINT message so that the program can control how the window is displayed.
When a user CLOSEs a window, the system sends a WM _ CLOSE message, if a program needs to do something before the window is closed, such as prompting the user to quit soon, the message needs to be intercepted in a window function, otherwise, the DestroyWindow function is called or the default window function of the system is directly handed over. The system sends a WM _ DESTROY message before destroying the window, and the program must call the PostQuitMessage to send a WM _ QUIT message when receiving the message to inform the system that the program can exit, otherwise, the window is destroyed but the process does not exit. Of course we can also handle some other things in the WM _ hierarchy message, like releasing resources etc. After the process exits, control will go back to CRuntime's Start code and I think that it should call ExitThread to exit the main thread. The system then calls ExitProcess to exit and enter, so that the running of a program is finished.
The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes performed by the present specification and drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims (10)

1. A method for a multi-window task scheduling mechanism based on a shared memory is characterized by comprising the following steps:
setting the number of task windows and the state of the task windows;
setting the processing priority of a task window by a thread scheduling method;
and dynamically adjusting the state of the task window through a window operation method.
2. The method according to claim 1, wherein the thread scheduling method comprises the steps of:
creating a shared memory space through a memory allocation function;
starting a scheduling thread through a thread function;
and circularly checking the queuing time of each task window in the shared memory until the thread is finished, and setting the window with the longest queuing time as the operation.
3. The method of claim 1, wherein the window operating method comprises the steps of:
registering a current task window to a shared memory;
setting the state of a current task window to be idle;
and circularly checking whether the task is received until the thread is finished, and if the task is received, setting the state of the task window into a queue and recording the queue starting time.
4. The method of claim 2, wherein the memory allocation function is expressed by equation 1 as:
CreateFileMapping<hFile><lpSecAttr><dwProtect><maxSizeHi><max SizeLo><lpName>
OpenFileMapping<dwAccess><isInherit><lpName>
MapViewOfFile<hMapFile><dwAccess><dwOffsetHi><dwOffsetLo><dwMapBytes>(1)
the CreateFileMapping represents the creation of a shared memory block, hFile represents a physical file handle, lpSetAttr represents security setting, dwProtect represents read-write protection setting, maxSizeHi represents the high-order 4 bytes of the size of a shared memory, maxSizeLo represents the low-order 4 bytes of the size of the shared memory, and lpName represents the name of the shared memory; returning the shared memory handle;
OpenFileMapping represents opening the shared memory, dwAccess represents read-write protection setting, isinheri represents whether the returned shared memory handle can be inherited, and lpName represents the name of the shared memory to be opened; and returning the shared memory handle.
5. The method of claim 3, wherein the threading function is represented by equation 2:
_beginthread<fpFunc><dwStackSize><lpArgs> (2)
where _ begin represents the thread started, fpFunc represents the thread execution function, dwStackSize represents the stack size of the new thread, lpArgs represents the parameters passed to the thread.
6. A system for a multi-window task scheduling mechanism based on a shared memory, comprising:
a global module: the method comprises the steps of setting an upper limit of the number of task windows and the state of the task windows;
a thread scheduling module: the priority level of the task window is set;
a window operation module: for dynamically adjusting the state of the task window.
7. The system of claim 6, further comprising a shared memory management device in a Linux operating system, the Linux operating system comprising a shmget shared memory management interface.
8. The system of claim 7, wherein the shmget shared memory management interface is configured to be invoked by an application to set attributes of read and write operations of the application to a cache.
9. A client comprising a memory, a processor and a computer program stored in the client and executable on the processor, characterized in that the processor implements the steps of the method according to any of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, in which a computer program is stored and which is applied to a client, characterized in that the computer program, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.
CN202210914900.1A 2022-07-29 2022-07-29 Method and system for multi-window task scheduling mechanism based on shared memory Pending CN115269149A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210914900.1A CN115269149A (en) 2022-07-29 2022-07-29 Method and system for multi-window task scheduling mechanism based on shared memory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210914900.1A CN115269149A (en) 2022-07-29 2022-07-29 Method and system for multi-window task scheduling mechanism based on shared memory

Publications (1)

Publication Number Publication Date
CN115269149A true CN115269149A (en) 2022-11-01

Family

ID=83746557

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210914900.1A Pending CN115269149A (en) 2022-07-29 2022-07-29 Method and system for multi-window task scheduling mechanism based on shared memory

Country Status (1)

Country Link
CN (1) CN115269149A (en)

Similar Documents

Publication Publication Date Title
US7631316B2 (en) Method and apparatus for providing and integrating high-performance message queues in a user interface environment
US5911068A (en) Container independent control architecture
US5421013A (en) Agent-based multithreading application programming interface
US6732138B1 (en) Method and system for accessing system resources of a data processing system utilizing a kernel-only thread within a user process
US8185895B2 (en) Method, apparatus and program storage device for providing an anchor pointer in an operating system context structure for improving the efficiency of accessing thread specific data
US20060031838A1 (en) Method and apparatus for implementing priority management of computer operations
US20090328058A1 (en) Protected mode scheduling of operations
JPH07121373A (en) Data processing system and its operating method
US20070101326A1 (en) Dynamic change of thread contention scope assignment
US8291426B2 (en) Memory allocators corresponding to processor resources
Bloom et al. Scheduling and thread management with RTEMS
US9417914B2 (en) Regaining control of a processing resource that executes an external execution context
US20080229220A1 (en) Multithreading iconic programming system
Sai et al. Producer-Consumer problem using Thread pool
CN111831432B (en) IO request scheduling method and device, storage medium and electronic equipment
CN115269149A (en) Method and system for multi-window task scheduling mechanism based on shared memory
US20070143436A1 (en) Method, apparatus and program storage device for providing light weight system calls to improve user mode performance
US6915408B2 (en) Implementation of thread-static data in multi-threaded computer systems
US9304831B2 (en) Scheduling execution contexts with critical regions
Dos Santos et al. On the design and implementation of real-time resource access protocols
EP0846288B1 (en) Portable object-oriented operating system
US8782675B2 (en) Method and system of accessing display window memory
Kulkarni Analysis of Process Structure in Windows Operating System
Vermeir Advanced. NET 6
US20100325098A1 (en) Eliding synchronization in a concurrent data structure

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination