Automatic dispatching scheme based on database non-waiting lock mechanism

Abstract

The application discloses an automatic dispatching scheme based on a database non-waiting lock mechanism, adopts the database non-waiting lock mechanism to solve the problem of resource contention, and realizes the problem of resource priority through self-defined sorting rules, and the database non-waiting lock mechanism comprises an architecture model of the non-waiting lock mechanism and a resource lock table, and comprises the following steps: (1) when a device requests dispatching, updating the port state of the device to ReadyToLoad; (2) acquiring relevant resources, and taking a unique identifier of the resources as the NAME of a lock to acquire the lock; (3) after the lock is acquired, inserting a record into COM_CON_LOCKS; (4) performing business processing; (5) updating the port state of the device to ReserveToLoad, indicating that the device dispatching is completed; and (6) releasing the lock and submitting the transaction. The application improves the dispatching efficiency, does not bring operation and maintenance cost and hardware cost, and can be popularized to the whole semiconductor industry.

Description

Technical Field

[0001] This application relates to the field of semiconductor resource scheduling technology, specifically to an automatic dispatching scheme based on a database non-waiting lock mechanism. Background Technology

[0002] In the semiconductor industry, automation is extremely high, with factories often operating unmanned. Real-Time Dispatch (RTD) is an automated dispatch management system primarily responsible for finding the most suitable task for idle equipment and sending transport instructions to downstream transport systems, thus achieving full automation. Because the relationship between equipment and resources in a factory is n-1, multiple devices (with the same capabilities) may simultaneously request dispatch, leading to a situation where a single transport vehicle is dispatched to multiple devices. To address this issue, current technologies use FIFO (First-In, First-Out) queue middleware.

[0003] Typically, RTD systems are implemented based on FIFO queues. To ensure the availability of system queues and data consistency, additional queue middleware (such as ActiveMQ) needs to be introduced in the software to solve this problem.

[0004] Typically, semiconductor manufacturing involves a wide variety and large quantity of equipment, as well as a large number of resources (carriers). A single piece of equipment may have multiple processing functions and multiple loading and unloading ports, such as... Figure 1 Model of the equipment's loading / unloading port. Meanwhile, the workshop will have multiple production lines, each with multiple pieces of equipment; see [link / reference]. Figure 2 A floor plan of the production workshop. From Figure 1 and Figure 2 As can be seen, when a device or devices with similar capabilities simultaneously issue dispatch requests, they will compete for a resource (vehicle). Without a reliable mechanism for managing resources, a vehicle might be dispatched to multiple devices, or a deadlock might occur. The problem model is as follows: Figure 3 As shown. For Figure 3 In typical RTD (Resource Contention Detection) models, resource contention is addressed using a FIFO (First-In, First-Out) queue approach. Figure 4 The diagram shows a queue-based architecture model. Figure 4 It's easy to see that queue consumers can only consume in a single-threaded mode. If multi-threaded consumption were possible, resource contention would still occur. With only one consumer thread per queue, if the entire system has only one queue, all requests will accumulate in that queue. To improve efficiency, the number of queues must be adjusted. This usually requires modifying the program code or configuring a management system, and can be done in several ways:

[0005] 1. The queue configuration needs to be adjusted based on the existing resource situation;

[0006] 2. If the system needs to be updated, the data in the queue must be consumed before the update can be performed, which can easily lead to operational risks.

[0007] 3. If it is a simple self-developed queue, when there is data in the queue but a system crash occurs, the queue data is lost. After recovery, the unprocessed data is lost or inconsistent with the database data, which poses a risk of data inconsistency.

[0008] 4. A separate queue management interface needs to be developed to manage the rules, such as mapping different vehicles to different queue algorithms.

[0009] from Figure 4 As can be seen, queue middleware is actually a very complex problem, requiring consideration of message reliability, high availability, and data consistency, which undoubtedly increases the burden and system complexity. After careful analysis, the number of concurrent requests from multiple devices to the same vehicle is not very large. The requests are granular, down to the processing steps and corresponding recipes, with concurrent requests ranging from 0 to 100. Under these conditions, it is unnecessary to introduce a more complex queue to solve this problem.

[0010] In summary, the FIFO queue-based solution has the following problems:

[0011] 1) Because it is a FIFO queue, if the number of queue members is not divided reasonably, queue blocking may occur, resulting in low efficiency;

[0012] 2) Because production resources change in real time, system administrators need to adjust the number of queues according to the existing resource quantity. An imbalance between the number of resources and the number of queues can easily cause production accidents.

[0013] 3) Additional queue middleware servers are required, increasing hardware costs;

[0014] 4) In terms of software knowledge, it is necessary to increase knowledge of queue middleware management, and even recruit specialized talents in this area, which increases human and financial costs;

[0015] 5) The introduction of queue middleware increases the complexity of the system, which will bring certain difficulties in development and maintenance. Summary of the Invention

[0016] This application provides an automatic task dispatching scheme based on a database no-wait lock mechanism. It proposes to use the database's NoWait lock to solve the problems mentioned in the background technology, aiming to improve production efficiency, enhance system stability, and reduce system complexity.

[0017] This application is achieved through the following technical solution:

[0018] An automatic task dispatching scheme based on a database non-waiting lock mechanism is proposed. This scheme uses a database non-waiting lock mechanism to resolve resource contention and implements resource priority through a custom sorting rule. The database non-waiting lock mechanism includes an architecture model and a resource lock table, and specifically includes the following steps:

[0019] (1) When the device requests a work assignment, update the device's port status to ReadyToLoad;

[0020] (2) Obtain the relevant resources and use the unique identifier of the resource as the lock name to acquire the lock. This uses the database's For Update No Wait mechanism, which means that if the row lock cannot be acquired, it will return directly without causing lock waiting in the database. The SQL statement is as follows: SELECT * FROM COM_CON_LOCKS T WHERE T.LOCK_NAME=resource_name FOR UPDATE NO WAIT;

[0021] (3) After acquiring the lock, insert a record into COM_CON_LOCKS;

[0022] (4) Perform business processing;

[0023] (5) Update the device port status to ReserveToLoad, indicating that the device dispatch is complete;

[0024] (6) Release the lock and commit the transaction.

[0025] In a preferred embodiment, the resource lock table is COM_CON_LOCKS.

[0026] In a preferred embodiment, if acquiring the lock fails, the device dispatch fails, and the device cannot be idle, a timed task is introduced to query the device's port status as ReadyToLoad.

[0027] In a preferred embodiment, if the device dispatch fails, the status of the device port will also be updated to ReadyToLoad.

[0028] In a preferred embodiment, if there is a timed task (Watchdog) in the system that periodically queries the device port status and finds it to be ReadyToLoad, the device will be reassigned until the reassignment is completed.

[0029] In a preferred embodiment, the COM_CON_LOCKS table structure is as follows:

[0030] Beneficial effects:

[0031] This application employs the simplest architecture to solve the problem of resource contention in RTD dispatching, without increasing the complexity of the original system. Compared to the FIFO solution, it improves dispatching efficiency without incurring additional maintenance and hardware costs, and can be applied to the entire semiconductor industry, specifically including:

[0032] (1) By utilizing the No wait lock mechanism of the database, high concurrency of dispatch requests can be achieved, so that the system will not experience queue blocking, which greatly improves production efficiency.

[0033] (2) A series of sorting algorithms are provided, which can prioritize the production of certain orders according to user-defined sorting rules. Production priorities can be flexibly configured, which fundamentally avoids the poor quality caused by the long-term accumulation of certain batches of wafers.

[0034] (3) It is directly integrated into the main RTD project without the need for any middleware, which reduces system complexity and hardware resources;

[0035] (4) Simple to use and easy to maintain, reducing the difficulty of system maintenance. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the equipment / feeding port in the prior art of this application.

[0037] Figure 2 This is a schematic diagram of the production workshop structure in the prior art of this application.

[0038] Figure 3 This is a schematic diagram of the dispatching problem in the prior art of this application.

[0039] Figure 4 This is a schematic diagram of a queue-based architecture model in the prior art of this application.

[0040] Figure 5 This is a schematic diagram of an architecture model based on a non-waiting lock mechanism in one embodiment of this application.

[0041] Figure 6 This is a schematic diagram of a timed task processing flow in one embodiment of this application. Detailed Implementation

[0042] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings: These embodiments are implemented based on the technical solution of the present invention, and provide detailed implementation methods and specific operation processes, but the protection scope of the present invention is not limited to the following embodiments.

[0043] like Figure 5 , 6 As shown, an automatic task dispatching scheme based on a database non-waiting lock mechanism is proposed. This mechanism addresses resource contention by employing a database non-waiting lock mechanism and prioritizes resources through a custom sorting rule. The database non-waiting lock mechanism includes its architecture model and resource lock table, and specifically comprises the following steps:

[0044] (1) When the device requests a work assignment, update the device's port status to ReadyToLoad;

[0045] (2) Obtain the relevant resources and use the unique identifier of the resource as the lock name to acquire the lock. This uses the database's For Update No Wait mechanism, which means that if the row lock cannot be acquired, it will return directly without causing lock waiting in the database. The SQL statement is as follows: SELECT * FROM COM_CON_LOCKS T WHERE T.LOCK_NAME=resource_name FOR UPDATE NO WAIT;

[0046] (3) After acquiring the lock, insert a record into COM_CON_LOCKS;

[0047] (4) Perform business processing;

[0048] (5) Update the device port status to ReserveToLoad, indicating that the device dispatch is complete;

[0049] (6) Release the lock and commit the transaction.

[0050] If acquiring the lock fails, device assignment fails, and the device cannot remain idle, a scheduled task is introduced to check the device's port status to ReadyToLoad. If device assignment fails, the device port status will also be updated to ReadyToLoad. If there is a scheduled task (Watchdog) in the system that periodically checks the device port status to ReadyToLoad, the device will be reassigned until assignment is completed.

[0051] The resource lock table is COM_CON_LOCKS, and the structure of the COM_CON_LOCKS table is as follows:

[0052] This form was created by the applicant.

[0053] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. An automatic work dispatching scheme based on a database non-waiting lock mechanism, characterized in that, A database non-waiting lock mechanism is used to resolve resource contention issues, while resource priority is implemented through a custom sorting rule. This database non-waiting lock mechanism includes an architecture model and a resource lock table, and specifically includes the following steps: (1) When the device requests a work assignment, update the device's port status to ReadyToLoad; (2) Obtain the relevant resources and use the unique identifier of the resource as the NAME of the lock to acquire the lock. Here, the database's For Update No Wait mechanism is used. This mechanism means that if the row lock cannot be acquired, it will return directly without causing lock waiting in the database. The SQL statement is as follows: SELECT * FROM COM_CON_LOCKS T WHERE T.LOCK_NAME = resource_name FOR UPDATE NO WAIT; (3) After acquiring the lock, insert a record into COM_CON_LOCKS; (4) Perform business processing; (5) Update the device port status to ReserveToLoad, indicating that the device dispatch is complete; (6) Release the lock and commit the transaction; The resource lock table is COM_CON_LOCKS; If acquiring the lock fails, the device dispatch fails, and the device cannot be idle, a timed task is introduced to query the device's port status as ReadyToLoad. If the device dispatch fails, the status of the device port will also be updated to ReadyToLoad; If there is a scheduled task (Watchdog) in the system that periodically checks the device port status and finds it to be ReadyToLoad, the device will be reassigned until the reassignment is completed. The structure of the COM_CON_LOCKS table is as follows: CREATE TABLE COM_CON_LOCKS ( "CATEGORY" VARCHAR2(32), "LOCK_NAME" VARCHAR2(64) ) ALTER TABLE "COM_CON_LOCKS" ADD CONSTRAINT "PK_COM_CON_LOCKS" PRIMARY KEY("LOCK_NAME", "CATEGORY") USING INDEX "PK_COM_CON_LOCKS" ENABLE.

Images