DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR RESOLVING A DEADLOCK EVENT IN A NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3. PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present disclosure relates to network communication, and more particularly relates to resolving a deadlock event in the network.
BACKGROUND OF THE INVENTION
[0002] In a distributed system and cloud computing context, multiple processes are executed within a time frame which may, sometimes, cause deadlock. Deadlock refers to a situation when two or more processes/threads are each waiting for a resource held by another process/thread, and each process/thread waits for another process/thread, to complete an action, to release a lock. A deadlock may also refer to more than one processes/threads waiting for resources in a circular chain until the lock is released. Generally, only a process/thread holding a resource may release the resource, and typically the processes/threads will not release the resource until processing has been completed. In simpler terms, deadlock is a state of the distributed system and cloud computing system where progress is halted because conflicting processes/threads are unable to continue.
[0003] A deadlock in distributed system or computing system may arise if the system relies on resource allocation mechanisms which may be inefficient. The resource allocation mechanism may be used for accessing controls in the computing system, or shared resources, or files/programs with sharing attributes enabled.
[0004] In order to resolve deadlock certain systems with high reliability requirements may choose to ignore deadlocks altogether, assuming that they will occur infrequently, and the impact can be mitigated only when the system restarts manually or by other similar means. While in other scenarios, systems are employed to periodically detect deadlock using algorithms like resource allocation graphs or bankers' algorithm. Once a deadlock is detected, the system can recover by terminating one or more processes or pre-empting resources.
[0005] Deadlock is not only observed in computing system, but also in hardware like System-on-Chip (SoC) where multiple hardware or software components within the SoC are unable to make progress due to resource conflicts or synchronization issues. SoCs are also found in routers, and hence a router may also face a deadlock issue with the multiple Transmission Control Protocol (TCP) request coming from devices and applications alike.
[0006] Further the deadlock in hardware/computing may occur for multiple reasons like, multiple components within the hardware or programs within computing system may contend for shared resources such as memory, buses, or peripheral interfaces. If there is insufficient coordination or resource allocation mechanism in place, it can lead to deadlocks. For example, if two components/threads are simultaneously trying to access the same memory region, and one holds a lock while waiting for another resource held by the second component/thread, a deadlock can occur if the second component/thread is also waiting for the first component's lock.
[0007] The deadlock may arise from improper synchronization mechanisms between different components/threads. For example, if two or more components/threads are waiting for specific signals or events to occur before proceeding, and those signals or events are never triggered, a deadlock can happen.
[0008] Hardware deadlock may ascend if an interrupt service routine (ISRs) is not designed carefully. For instance, if an ISR tries to access a resource that is already held by another component, and that component is waiting for the ISR to complete before releasing the resource, a deadlock can arise.
[0009] Further, communication mechanisms like message passing or shared memory can also be a source of deadlocks. If components engage in blocking communication and get stuck waiting for messages from each other, a deadlock can occur.
[0010] The current state of art discloses implementation of deadlock detection algorithms that periodically analyze the system state to identify potential deadlocks. If a deadlock is detected, appropriate recovery mechanisms can be invoked, such as resource preemption or process termination, to resolve the deadlock.
[0011] Further, in a multi-threaded software, multiple threads execute concurrently and perform various tasks. Due to complexity of the system and the interdependencies among threads, applications use mutexes and semaphores to protect resources while being used by a thread to protect against data inconsistency and corruption. However, due to some coding bug or unhandled event, deadlock can occur. Deadlocks can lead to some threads freeze or system freeze and can be challenging to identify and resolve. While in partial or full system deadlock, without auto-detection and auto-recovery, significantly impacts system responsiveness and throughput. The issue needs to be addressed.
[0012] Therefore, there is a need for a system and method configured to detect and resolve the deadlock at the process level to improve operational efficiency and service quality.
BRIEF SUMMARY OF THE INVENTION
[0013] One or more embodiments of the present disclosure provide a system and a method for resolving a deadlock event in a network.
[0014] In one aspect of the present invention, a system for resolving a deadlock event in a network is disclosed. The system includes a registration module. The registration module is configured to receive a request for a thread registration from a thread initiating device and capture data pertaining to the thread requesting for thread registration and completing the thread registration. The system includes a detection module configured to initiate a deadlock detection task by periodically transmitting signals to the registered thread and detect occurrence of a deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than a pre-defined threshold. The pre-defined threshold is the minimum number of times of responses from the registered thread within a pre-defined time period. The system includes a recovery module configured to initiate a standby process until the deadlock event is resolved. The recovery module is further configured to gather information about the registered thread experiencing the deadlock event. The recovery module is further configured to capture stack trace of the registered thread for ascertaining root cause of the deadlock event, thereby facilitating post-recovery debugging.
[0015] In an embodiment, the received request for the thread registration from the thread initiating device includes at least one of a request generated voluntarily and a request generated manually using the thread initiating device. The request is intended to register the thread such that the thread is protected against the deadlock event. In an embodiment, the periodic transmission of signals to the registered thread is performed by utilizing an auditor thread to detect occurrence of the deadlock event.
[0016] In another aspect of the present invention, a method for resolving a deadlock event in a network is disclosed. The method includes the step of receiving a request for a thread registration from a thread initiating device. The method includes the step of capturing data pertaining to the thread requesting for the thread registration and completing the thread registration. The method further includes the step of initiating a deadlock detection task by periodically transmitting signals to the registered thread. Thereafter, the method includes step of detecting occurrence of a deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than a pre-defined threshold. The pre-defined threshold is the minimum number of times of responses from the registered thread within a pre-defined time period. The method includes the step of initiating a standby process until the deadlock event is resolved.
[0017] In an embodiment, the received request for the thread registration from the thread initiating device includes at least one of request generated voluntarily and generated manually using the thread initiating device. The request is intended to register the thread such that the thread is protected against the deadlock event. The method further includes step of utilizing an auditor thread to detect occurrence of the deadlock event. The method further includes step of periodically transmitting signals to the registered thread utilizing the auditor thread. The method includes the steps of gathering information about the registered thread experiencing the deadlock event. The method includes the step of capturing stack trace of the registered thread for ascertaining root cause of the deadlock event, thereby facilitating post-recovery debugging.
[0018] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0020] FIG. 1 is an exemplary block diagram of an environment for resolving a deadlock event in a network, according to various embodiments of the present invention;
[0021] FIG. 2 is a block diagram of the system for resolving the deadlock event in the network, according to various embodiments of the present invention;
[0022] FIG. 3 is a schematic representation of the system of FIG. 1, according to various embodiments of the present invention;
[0023] FIG. 4 shows a flow diagram of a method for resolving the deadlock event in the network, according to various embodiments of the present invention;
[0024] FIG. 5 is a schematic representation of the system of FIG. 1 for identifying root cause of the deadlock event in the network, according to various embodiments of the present invention; and
[0025] FIG. 6 shows a flow diagram of a method for identifying the root cause of the deadlock event, according to various embodiments of the present invention.
[0026] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0027] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0028] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0029] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0030] As per various embodiments depicted, the present invention discloses the system and method for resolving the deadlock event in the network. The system and method is more particularly intended for detecting the deadlock and automatic recovery of the network. The system and method is further intended for predicting the deadlock event in the network having multiple threads. Further, the system and method is intended for initiating a recovery mechanism to capture detailed information regarding the occurrence of the deadlock event, including specific location and sequence of the deadlock event and thereafter triggering recovery action as required.
[0031] FIG. 1 illustrates an exemplary block diagram of an environment 100 for resolving the deadlock event in the network 105, according to one or more embodiments of the present invention. The environment 100 includes a thread initiating device 110. For the purpose of description and explanation, and as per the illustrated embodiment, the thread initiating device 110 includes a first thread initiating device 110a, a second thread initiating device 110b, and a third thread initiating device 110c. However, it is to be understood, that the thread initiating device 110 may include one or more thread initiating devices and should nowhere be construed as limiting the scope of the present disclosure.
[0032] In an embodiment, each of the first thread initiating device 110a, the second thread initiating device 110b, and the third thread initiating device 110c may be one of, but are not limited to, a computer system with one or more communication ports coupled to one or more communication bus, an user equipment with an interface, a wireless device including, by the way of example not limitation, a handheld wireless communication device (such as a mobile phone, a smart phone, and a phablet device), a wearable computer device (such as a head-mounted display computer device, a head-mounted camera device, and a wristwatch computer device), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities.
[0033] In an embodiment, the one or more communication ports of the computer system may be, by the way of example not limitation, any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication ports may be chosen depending on the network 105.
[0034] In an embodiment, the one or more communication bus may be, but not limited to only the following examples, a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), universal serial bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects a processor to the computer system.
[0035] In an embodiment, each of the first thread initiating device 110a, the second thread initiating device 110b, and the third thread initiating device 110c may further include one or more applications. The one or more applications is configured to interact with the remote server 115 over the network 105 for initiating one or more threads. The one or more threads is defined as components of the network 105 capable of executing activities such as, but not limited to, exchanging data between at least one of the thread initiating device 110 and the remote server 115. The remote server 115 may include one of, but not limited to, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise, a defense facility, or any other facility that provides content.
[0036] The network 105 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The network 105 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0037] The network 105 includes, by the way of example but not limitation, one or more wireless interfaces/protocols such as, for example, 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, Radio Frequency (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0038] The environment further includes a system 125 communicably coupled to the remote server 115, a database 240 and each of the thread initiating device 110, via the network 105. The system 125 is configured to resolve deadlock in the network 105.
[0039] The database 240 may be incorporated within the remote server 115 or an independent storage unit coupled to the system 125. The database 240 can be one of, but not limited to, one of a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 240 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0040] In various embodiments, the system 125 may be generic in nature and may be integrated with any application including a System Management Facility (SMF), an Access and Mobility Management Function (AMF), a Business Telephony Application Server (BTAS), a Converged Telephony Application Server (CTAS), any SIP (Session Initiation Protocol) Application Server which interacts with core Internet Protocol Multimedia Subsystem(IMS) on Industrial Control System (ISC) interface as defined by 3GPP to host a wide array of cloud telephony enterprise services, a System Information Blocks (SIB)/ and a Mobility Management Entity (MME).
[0041] Operational and construction features of the system 125 will be explained in detail with respect to the following figures.
[0042] Referring to FIG. 2, FIG. 2 illustrates a block diagram of the system 125 for resolving deadlock in the network 105, according to one or more embodiments of the present invention. The system 125 is adapted to be embedded within the remote server 115 or is embedded as the individual entity. However, for the purpose of description, the system 125 is described as an integral part of the remote server 115, without deviating from the scope of the present disclosure.
[0043] As per the illustrated embodiment, the system 125 includes one or more processors 205, a memory 210, and an input/output interface unit 215. The one or more processors 205, hereinafter referred to as the processor 205 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system 125 includes one processor 205. However, it is to be noted that the system 125 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. Among other capabilities, the processor 205 is configured to fetch and execute computer-readable instructions stored in the memory 210. The memory 210 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 210 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0044] In an embodiment, the input/output (I/O) interface unit 215 includes a variety of interfaces, for example, interfaces for data input and output devices, referred to as Input/Output (I/O) devices, storage devices, and the like. The I/O interface unit 215 facilitates communication of the system 125. In one embodiment, the I/O interface unit 215 provides a communication pathway for one or more components of the system 125. Examples of such components include, but are not limited to, the thread initiating device 110 and a remote server 115.
[0045] Further, the processor 205, in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 205. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 205 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for processor 205 may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 210 may store instructions that, when executed by the processing resource, implement the processor 205. In such examples, the system 125 may comprise the memory 210 storing the instructions and the processing resource to execute the instructions, or the memory 210 may be separate but accessible to the system 125 and the processing resource. In other examples, the processor 205 may be implemented by electronic circuitry.
[0046] In order for the system 125 to resolve the deadlock event in the network 105, the processor 205 includes a registration module 220, a detection module 225, and a recovery module 230, communicably coupled to each other.
[0047] The registration module 220 of the processor 205 is communicably connected to the thread initiating device 110, via the network 105. Accordingly, the registration module 220 is configured to receive at least one input from the thread initiating device 110. The at least one input corresponds to a request for registering a thread from the thread initiating device 110.
[0048] In a preferred embodiment, the registration module 220 is configured to receive the request for the thread registration from the thread initiating device 110 via the input/output interface 215 communicably coupled to the registration module 220.
[0049] In one embodiment, the request for the thread registration includes at least one of a request generated voluntarily and a request generated manually using the thread initiating device 110.
[0050] The registration module 220 is further configured to capture data pertaining to the thread based on the received request as well as data pertaining to the completion of registration of the thread.
[0051] In an embodiment, the data pertaining to one or more threads in the network 105 is stored in the database 240. Accordingly, the registration module 220 is configured to retrieve the data pertaining to the thread which is to be registered into the system 125 from the database 240, in response to receiving the thread registration request from the thread initiating device 110. The registration module 220 is further configured to store data pertaining to the thread registration upon completing the thread registration in the database 240. Registering the thread into the system 125 by the registration module 220 enables the system 125 to perform organized assessment of the registered thread such that the registered thread is protected against the deadlock event. The data pertaining to the thread for registration may include one of a thread ID (thread identifier) and a thread priority. The thread ID is a unique numeric identifier assigned to the thread. The thread priority pertains to a pre-defined order in which the thread is scheduled for initiation. The pre-defined order is set by a network service operator.
[0052] In another embodiment, the registration module 220 is further configured to register the thread into the system 125 and thereafter store the information pertaining to the registered thread in the memory 210.
[0053] The processor 205 further includes the detection module 225 in communication with registration module 220. More specifically, the detection module 225 is communicably coupled with the registration module 220 to receive data pertaining to the registered thread for detecting the deadlock event in the registered thread.
[0054] In one embodiment, the detection module 225 is configured to detect the deadlock event in the registered thread by initiating a deadlock detection task. The deadlock detection task includes periodical transmission of signals to the registered thread by the detection module 225. The periodic signal is one of a pulse signal, a sinusoidal signal, a non-sinusoidal signal, a discreet time signal, and a text-based signal.
[0055] Accordingly, the detection module 225 is configured to detect occurrence of the deadlock event when number of responses received back from the registered thread corresponding to the periodically transmitted signals is less than a pre-defined threshold. The pre-defined threshold is a pre-defined number of times the detection module receives the response from the registered thread within a pre-defined time period. In one embodiment, the pre-defined threshold may be defined by the network service operator. The pre-defined time period is set by at least one of the network service operator via the input/output interface 215 of the system 125. The pre-defined time period corresponds to a time period within which the detection module 225 is configured to transmit the signals in order to detect occurrence of the deadlock event.
[0056] For example, during operation, the detection module 225 is configured to periodically transmit at least 10 pulse signals to the registered thread for the pre-defined time period. The pre-defined time period being at least one 1 minute. The network service operator further defines the pre-defined threshold to at least 5 responses to the pulse signals. Taking into consideration the pre-defined threshold and the pre-defined time period, the detection module 225 monitors the number of responses received from the registered thread in response to pulse signal transmitted. If the detection module 225 fails to receive 5 or more signal responses from the registered thread within the pre-defined time period, the detection module 220 ascertains that the registered thread has experienced deadlock.
[0057] In an embodiment, the detection module 225 utilizes an auditor thread to periodically transmit signals to the registered thread to detect occurrence of the deadlock event. Accordingly, the detection module 225 is further configured to transmit a trigger for initiation of a recovery mechanism, by utilizing the auditor thread. The detection module 225 transmits the trigger for initiation of the recovery mechanism when the registered thread fails to respond to the periodically transmitted signals continuously for the pre-defined time period. Thus, the system 125 detects the deadlock.
[0058] .
[0059] The recovery module 230 of the processor 205 is communicably connected to the detection module 225. Upon detection of the deadlock event, the recovery module 230 is configured to receive the trigger from the detection module 225 to initiate the recovery mechanism. Upon receiving the trigger from the detection module 225, the recovery module 230 is configured to initiate a standby process until the deadlock event is resolved.
[0060] The recovery module 230 is further configured to gather information about the registered thread experiencing the deadlock event by capturing stack trace of the registered thread for ascertaining root cause of the deadlock event. The stack trace captures sequence of a workflow call of the registered thread and respective execution context pertaining to the workflow call of the registered thread, allowing the networking expert to inspect the state of the registered threads at the time of deadlock. The recovery module 230 thereby enables the system 125 to provide ease of identifying and fixing underlying issues that may have contributed to occurrence of the deadlock event.
[0061] Referring to FIG. 3, FIG. 3 describes a preferred embodiment of the system 125 for resolving the deadlock event in the network 105. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the thread initiating device 110 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0062] As mentioned earlier, the thread initiating device 110 includes one or more primary processors 305 communicably coupled to the one or more processors 205 of the system 125. The one or more primary processors 305 are coupled with a memory unit 310 storing instructions which are executed by the one or more primary processors 305. Execution of the stored instructions by the one or more primary processors 305 enables the thread initiating device to transmit the request for the thread registration to the one or more processors 205.
[0063] In the preferred embodiment, the registration module 220 of the processor 205 is communicably connected to the thread initiating device 110. The registration module 220 is configured to receive the request to register the thread into the system 125 for further observation, detection and resolution in case of the deadlock event.

[0064] In the preferred embodiment, the detection module 225 of the processor 205 is communicably connected to the registration module 220 to receive data pertaining to the registered thread. Upon receiving the data, the detection module 225 initiates the deadlock detection task by periodically transmitting signals to the registered thread. When number of responses received from the registered thread for the periodically transmitted signals is less than the pre-defined threshold, then the detection module 225 confirms occurrence of the deadlock event and thereafter, the detection module is configured to transmit the trigger to initiate the recovery mechanism.
[0065] The processor 205 further includes the recovery module 230 in communication with the detection module 225. Upon detection of the deadlock event in the registered thread the recovery module 230 is configured to receive the trigger to initiate the recovery mechanism from the detection module 225. Upon receiving the trigger from the detection module 225, the recovery module 230 is configured to initiate the standby process until the deadlock event is resolved. Thereby the operational efficiency of the system is not compromised while deadlock resolution is in continuation. The recovery module 230 is further configured to gather information about the registered thread experiencing the deadlock event and capture the stack trace of the registered thread for ascertaining root cause of the deadlock event.
[0066] FIG. 4 illustrates a flow chart of the method 400 for resolving the deadlock event in the network 105, according to one or more embodiments of the present invention. The method 400 is adapted to detect occurrence of the deadlock event in one or more threads and resolve the deadlock event. More specifically, the method further captures data pertaining to the deadlock event to facilitate ease of post-recovery debugging. For the purpose of description, the method 400 is described with the embodiments as illustrated in FIG 2-3 and should nowhere be construed as limiting the scope of the present disclosure.
[0067] At step 405, the method 400 includes the step of receiving, by the one or more processors 205, the request for the thread registration from the thread initiating device 110. The request is one of a request generated voluntarily and a request generated manually using the thread initiating device 110.
[0068] At step 410, the method 400 includes the step of capturing, by the one or more processors 205, data pertaining to the thread for registration, based on the received request from the thread initiating device 110 as well as the data pertaining to the completion of the thread registration.
[0069] The thread registration includes registering a thread into the system 125 by the registration module 220. The registration module 220 is configured to capture the data pertaining to the thread. The data pertaining to the thread for registration may include one of a thread ID (thread identifier) and a thread priority. The thread ID is a unique numeric identifier assigned to the thread. The thread priority pertains to a pre-defined order in which the thread is scheduled for initiation. The pre-defined order is set by a network service operator. By registering the thread, the system 125 is enabled to monitor the registered thread, detect and resolve the deadlock event occurred in the registered thread.
[0070] At step 415, the method 400 includes the step of initiating, by the one or more processors 205, the deadlock detection task by periodically transmitting signals to the registered thread, upon completion of registering the thread. The method 400 utilizes the auditor thread to periodically transmit signals to the registered thread to detect occurrence of the deadlock event.
[0071] At step 420, the method 400 includes the step of detecting, by the one or more processors 205, occurrence of the deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than the pre-defined threshold.
[0072] At step 425, the method 400 includes the step of initiating, by the one or more processors 205, the standby process until the deadlock event is resolved.
[0073] In order to facilitate the post-recovery debugging in case of deadlock event in the registered thread, the method 400 is further configured to gather information about the registered thread experiencing the deadlock event. The method includes the step of capturing the stack trace of the registered thread for ascertaining root cause of the deadlock event.
[0074] FIG. 5 illustrates the system 125 for identifying a root cause of the deadlock event in the network 105 utilizing the recovery module 230, according to one or more embodiments of the present invention.
[0075] With reference to the illustrated embodiment in FIG. 5 and the FIG. 3, upon registering the thread in response to receiving the request for thread registration from the thread initiating device 110, the registration module 220 is configured to transmit the data pertaining to the registered thread to the detection module 225 of the processor 205. Thereafter, the detection module 225 initiates the deadlock detection task to monitor the registered thread and to detect the deadlock event.
[0076] On detection, the recovery module 230, is configured to receive the data pertaining to the registered thread where the deadlock event has occurred. In this regard, the recovery module 230 is configured to include an application module 505 and a standby initiation module 510 communicably coupled to the application module 505. The application module 505 is communicably connected to the detection module 225 to receive the data pertaining to the registered thread, hereinafter referred to as “the thread” where the deadlock event has occurred.
[0077] On receipt of the thread, the application module 505 is configured to capture data pertaining to the deadlock event by performing stack trace on the said affected thread. The data pertaining to the deadlock event includes one of, but not limited to, information on the thread including the thread ID, the thread priority, a thread state including one of a running state, a blocked state and a waiting state, one or more resources of the system 125 reserved by the thread and the one or more resources of the system 125 required by the thread, and information on a lock utilized by the thread. The one or more resources of the system 125 include one of, but not limited to, a Central Processing Unit (CPU) percentage and Random Access Memory (RAM). The lock is utilized by the thread to reserve the one or more resources. The lock may be one of, but not limited to, a Mutex, a Semaphore, a Reentrant, and a Read-Write Lock.
[0078] The application module 505 utilizes the captured data to identify the root cause of the deadlock event. In one embodiment, the application module 505 is further configured to restart the thread to ensure that the standby process is smoothly initiated.
[0079] The recovery module 230 further includes a standby initiation module 510 communicably connected to the application module 505. The standby initiation module 510 is configured to receive an input from the application module 505 after the thread is restarted. The input corresponds to initiating a standby process until the deadlock event is resolved by the application module 505.
[0080] FIG. 6 illustrates a flow diagram of the method 600 for identifying the root cause of the deadlock event, according to various embodiments of the present invention.
[0081] At step 605, the method 600 includes the step of transmitting by the one or more processor 205, the data pertaining to the registered thread, upon registering the thread in response to receiving the request for thread registration from the thread initiating device 110.
[0082] At step 610, the method 600 includes the step of initiating by the one or more processor 205, the deadlock detection task to monitor the registered thread and to detect the deadlock event.
[0083] At step 615, the method 600 includes the step of receiving by the one or more processor 205, the data pertaining to the registered thread where the deadlock event has occurred, upon detecting the deadlock event.
[0084] At step 620, the method 600 includes the step of capturing by the one or more processor 205, the data pertaining to the deadlock event by performing stack trace on the thread where the deadlock event has occurred.
[0085] The data pertaining to the deadlock event includes one of, but not limited to, information on the thread including the thread ID, the thread priority, the thread state including one of the running state, the blocked state and the waiting state, the one or more resources of the system 125 reserved by the thread and the one or more resources of the system 125 required by the thread, and information on the lock utilized by the thread.
[0086] At step 625, upon detection of deadlock event, the method 600 includes the step of identifying by the one or more processor 205, the root cause of the deadlock event by utilizing the captured data pertaining to the deadlock event.
[0087] At step 630, the method 600 includes the step of restarting, by the one or more processor 205, the thread where deadlock event has occurred. Accordingly, by restarting the thread where the deadlock event has occurred ensures smooth initiation of the standby process.
[0088] Moreover, restarting the thread results in maintaining a high availability of the system 125 to handle any further incoming requests for thread registration and to monitor registered threads. Furthermore, restarting the thread results in improved fault tolerance capability of the network 105 by redistributing the workload among active threads in the network
[0089] Subsequent to restarting the thread, at step 635, the method 600 includes the step of initiating, by the one or more processor 205, the standby process until the deadlock event is resolved.
[0090] In an embodiment, the present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by a processor 205. The processor 205 is configured to receive the request for the thread registration from the thread initiating device 110. The processor 205 is further configured to capture data pertaining to the thread requesting for thread registration based on the received request from the thread initiating device 110 and data pertaining to completing the thread registration. The processor 205 is further configured to initiate a deadlock detection task by periodically transmitting signals to the registered thread. The processor 205 is further configured to detect occurrence of a deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than a pre-defined threshold and therefore, to initiate a standby process until the deadlock event is resolved.
[0091] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG. 1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0092] The present disclosure significantly reduces, by incorporating efficient deadlock detection and resolution mechanism, the operational downtime and improves system throughput enabling faster detection of deadlock event.
[0093] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS
[0094] Environment - 100;
[0095] Communication Network - 105;
[0096] Thread Initiating Device- 110;
[0097] Primary processors -305;
[0098] Memory Unit of User Equipment – 310;
[0099] Remote Server - 115;
[00100] System - 125;
[00101] Memory – 210;
[00102] One or more processor -205
[00103] Registration Module- 220;
[00104] Detection Module - 225;
[00105] Recovery Module - 230;
[00106] Database - 240;
[00107] Application module– 505;
[00108] Standby initiation module – 510.

,CLAIMS:CLAIMS
We Claim:
1. A method (400) for resolving a deadlock event in a network, the method comprises the steps of:
receiving, by one or more processors (205), a request for a thread registration from a thread initiating device (110);
capturing, by the one or more processors (205), data pertaining to the thread requesting for the thread registration and completing the thread registration;
initiating, by the one or more processors (205), a deadlock detection task by periodically transmitting signals to the registered thread;
detecting, by the one or more processors (205), occurrence of a deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than a pre-defined threshold; and
initiating, by the one or more processors (205), a standby process until the deadlock event is resolved.

2. The method as claimed in claim 1, wherein the request is received from the thread initiating device (110) for the thread registration includes at least one of, request generated voluntarily, and generated manually using the thread initiating device.

3. The method as claimed in claim 1, wherein the request is intended to register the thread such that the thread is protected against the deadlock event.

4. The method as claimed in claim 1, wherein an auditor thread is utilized by the one or more processors (205) to detect occurrence of the deadlock event, wherein the one or more processors utilizing the auditor thread periodically transmit signals to the registered thread.

5. The method as claimed in claim 1, wherein the pre-defined threshold is the minimum number of times the one or more processors (205) is required to receive responses from the registered thread within a pre-defined time period.

6. The method as claimed in claim 1, wherein the method further comprises the steps of:
gathering, by the one or more processors (205), information about the registered thread experiencing the deadlock event; and
capturing, by the one or more processors (205), stack trace of the registered thread for ascertaining root cause of the deadlock event, thereby facilitating post-recovery debugging.

7. A system (125) for resolving a deadlock event in a network, the system comprising:
a registration module (220) configured to:
receive, a request for a thread registration from a thread initiating device (110); and
capture, data pertaining to the thread requesting for thread registration and completing the thread registration;
a detection module (225) configured to:
initiate, a deadlock detection task by periodically transmitting signals to the registered thread; and
detect, occurrence of a deadlock event when number of responses received from the registered thread for the periodically transmitted signals is less than a pre-defined threshold; and
a recovery module (230) configured to, initiate, a standby process until the deadlock event is resolved.

8. The system as claimed in claim 7, wherein the request is received from the thread initiating device (110) for the thread registration includes at least one of, request generated voluntarily, and generated manually using the thread initiating device (110).

9. The system as claimed in claim 7, wherein the request is intended to register the thread such that the thread is protected against the deadlock event.

10. The system as claimed in claim 7, wherein the detection module (225) is configured to utilize an auditor thread to detect occurrence of the deadlock event, wherein the detection module utilizing the auditor thread periodically transmit signals to the registered thread.

11. The system as claimed in claim 7, wherein the pre-defined threshold is the minimum number of times the one or more processors is required to receive responses from the registered thread within a pre-defined time period.

12. The system as claimed in claim 7, wherein the system is further configured to:
gather, by the recovery module (230), information about the registered thread experiencing the deadlock event; and
capture, by the recovery module (230), stack trace of the registered thread for ascertaining root cause of the deadlock event, thereby facilitating post-recovery debugging.

13. A thread initiating device (110), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (205), the one or more primary processors (305) coupled with a memory (310), wherein said memory stores instructions which when executed by the one or more primary processors causes the thread initiating device (110) to:
transmit, a request for thread registration to the one or more processors (205); and
wherein the one or more processors is configured to perform the steps as claimed in claim 1.