Monitoring changes to data within a critical section of a threaded program

A method, system and program product for monitoring changes to a variable within a critical section of a threaded program. The method includes establishing, using a debugging tool, a watch for monitoring changes to a variable that occur outside of the critical section and executing a portion of the threaded program with a debugger. Further, the method includes determining, using the tool, whether or not a thread has executed a start breakpoint set for the critical section, if the thread has executed the start breakpoint set, determining whether or not the thread has executed an end breakpoint set for the critical section, and if the thread has not executed the end breakpoint set, displaying any watches triggered responsive to updates to the variable that occur outside of the critical section, such that, only updates to the variable that occur outside of the critical section will trigger the displaying.

FIELD OF THE INVENTION

The present invention relates to computer systems and software, and more specifically to an automated technique for monitoring changes to data, for instance, a variable, within a critical section of a threaded program being debugged.

BACKGROUND OF THE INVENTION

Multi-threaded software provides multiple execution “threads” which act like independently executing programs. An advantage to such multi-threaded software is that each thread can be assigned to an independent processor, or to a single processor that provides multi-threaded execution so that the threads may be executed in parallel for improved speed of execution. Each of the threads in a multi-threaded program may need to modify common data shared among the threads. However, if the threads are not coordinated in their use of the common data, serious errors can occur. Typically, a programmer uses another computer program commonly referred to as a “debugger” to “debug” a multi-threaded program under development to ensure that all aspects of a multi-threaded program employed are operational, and that any critical situations that may occur are not missed during debugging. As such, there is a need for programmers to effectively identify, locate, analyze and/or correct suspected faults in a multi-threaded program during the process of “debugging” a program.

SUMMARY OF THE INVENTION

The present invention resides in a system, method and program product for monitoring changes to data within a critical section of a threaded program being debugged, where the changes are made by code running outside of the critical section. The method includes establishing, using a tool coupled to a debugger, a watch for monitoring changes to a variable that occur outside of the critical section of the threaded program, executing a portion of the threaded program with the debugger, and determining, using the tool coupled to the debugger, whether or not a thread of the threaded program has executed a start breakpoint set for the critical section. If the thread has executed the start breakpoint set for the critical section, determining, using the tool coupled to the debugger, whether or not the thread of the threaded program has executed an end breakpoint set for the critical section, and if the thread has not executed the end breakpoint set for the critical section, displaying any watches triggered responsive to updates to the variable that occur outside of the critical section of the threaded program, wherein only updates to the variable that occur outside of the critical section of the threaded program will trigger the displaying. In an embodiment, if the thread has executed the end breakpoint set for the critical section, ignoring any watches triggered by the thread executing within the critical section. In an embodiment, the establishing step further includes selecting the variable within the critical section of the program to be watched by the tool within the debugger program. In an embodiment, the establishing step further includes identifying a starting line and an ending line of said critical section of said program to be watched, and setting a start breakpoint and an end breakpoint corresponding to said starting line and said ending line identified for said critical section of said program. In an embodiment, determining whether or not the thread of the threaded program has executed the start breakpoint set for the critical section step, further includes adding the thread executing within the critical section to a thread list, wherein the tool ignores any watches generated responsive to the thread being executed within the critical section of the threaded program. In an embodiment, the displaying step further includes reporting a location within the threaded program of any updates to the variable outside of the critical section. In an embodiment, the threaded program is either a multi-threaded program or a single threaded program.

DETAILED DESCRIPTION OF THE INVENTION

Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. Modules may also be implemented in software for execution by various types of processors. An identified module or component of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Further, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, over disparate memory devices, and may exist, at least partially, merely as electronic signals on a system or network. Furthermore, modules may also be implemented as a combination of software and one or more hardware devices. For instance, a module may be embodied in the combination of a software executable code stored on a memory device. In a further example, a module may be the combination of a processor that operates on a set of operational data. Still further, a module may be implemented in the combination of an electronic signal communicated via transmission circuitry.

Moreover, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents. Reference will now be made in detail to the preferred embodiments of the invention.

Reference is now made toFIGS. 1 and 2, reference numeral100and200, respectively, which illustrate embodiments of a computer infrastructure102for monitoring changes to data, for instance, a variable within a critical section of a threaded program that occur as a result of changes made outside of the critical section, in accordance with an embodiment of the invention. Turning toFIG. 1,FIG. 1depicts a schematic block system diagram illustrating one embodiment of a computer infrastructure100, which includes computer system104configured for monitoring changes to a variable (or storage that stores a piece of information) within a critical section of a threaded program that occur as a result of threads running outside of the critical section. As depicted inFIG. 1, system100includes a computer infrastructure102, which is intended to represent any type of computer architecture that is maintained in a secure environment (i.e., for which access control is enforced). It should be understood, however, that although not shown, other hardware and software components (e.g., additional computer systems, routers, firewalls, etc.) could be included in infrastructure102. As shown, infrastructure102includes a computer system104that typically represents a debugging server or system104or the like that includes at least one central processing unit (CPU) or processor106, which obtains instructions, or op codes, and data via a network from main memory112. Further, the main memory112includes an operating system114, which in an embodiment, comprises an operating system configured to run multi-threaded programs in a computer system, such as, the IBM® i5 operating system used on an IBM Power Systems computers or the IBM® z series operating system used for mainframe computers. The IBM® i5 operating system and the IBM® z series operating system are both commercially available from International Business Machines Corporation (IBM). Further, the main memory112of computer system100has stored thereon a threaded program116, which in an embodiment, comprises a multi-threaded program being debugged by the computer system104. However, it is understood by one skilled in the art that the invention may be used in conjunction with a single threaded program for detecting areas of interest to a programmer, where a variable is not being updated correctly. As shown inFIG. 1, the main memory112further has deployed thereon a debugger program (also referred to herein as a debugging program or simply a debugger)118for debugging the threaded program116. In an embodiment, the debugger118includes a critical section watch tool120(also referred to herein as the debugging tool), which is discussed further herein below with respect toFIG. 3. Although, the critical section watch tool120is shown incorporated within the debugger118, it is understood by one skilled in the art that the critical section watch tool120may be designed as a separate plug-in to the debugger118.

Reference is now made toFIG. 2, reference numeral200, which depicts a schematic block system diagram illustrating one embodiment of a computer system200for monitoring changes to a variable within a critical section of a threaded program216being debugged by a debugger218running on operating system214within a main memory212of critical section200. In an embodiment, the debugger program218is stored within a main memory212of the computer system204. In an embodiment, shown inFIG. 2, the debugger program218includes a critical section watch tool220for monitoring changes to a variable within the critical section of the threaded program216being debugged, in accordance with an embodiment of the invention. Computer system200includes at least one central processing unit (CPU) or processor206which obtains instructions, or op codes, and data via a network from main memory212. The processor206could be a PC-based server, a minicomputer, a midrange computer, a mainframe computer, etc. Further, the main memory212includes a programming environment222that provides a mechanism to debug the threaded program216. In an embodiment, the programming environment222includes a debug user interface224, an expression evaluator226, a code interpreter228, a break point manager230, a break point table232, a debugger hook234, and a result buffer235. The threads are suspended and released selectively by the break point manager230. In an embodiment, the main memory212comprises a memory device or a combination of memory devices, including Random Access Memory (RAM), nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories (ROM), etc.). In addition, memory212may include memory storage physically located elsewhere in the computer system200, for instance, any storage capacity used as virtual memory or stored on a mass storage device or on another computer coupled to computer system200via network238. In an embodiment, the computer system200may include a number of operators and peripheral systems as shown, for example, a network interface240operably connected to a plurality of network devices (network device1through network device N, reference numeral246through reference numeral249), a mass storage interface242operably connected to a storage device250, and a terminal interface244operably connected to a terminal254. As shown inFIG. 2, a storage medium or media252may be used to load programs into computer system200. In an embodiment, the terminal254and network devices1through N can include desktop or PC-based computers, workstations, or network terminals, or other networked computer systems. For purposes of the invention, computer system200may represent practically any type of computer, computer system or other programmable electronic device, including a client computer, a server computer, a portable computer, an embedded controller, etc. The computer system200may be a standalone device or networked into a larger system.

Referring to the programming environment222, in an embodiment, the debug user interface224provided is used by a user and/or programmer to initiate a critical section watch for a variable within the critical section. For example, a programmer uses a WATCH command provided within the debugger218to select a variable (for instance, variable A) to be watched and then selects the starting line or statement and the ending line or statement of the critical section (for example, line23and line41), which in an embodiment, may be entered as WATCH A CS(23,41), such that, threads executing between these statements or lines are allowed to update the variable. Accordingly, memory addresses may be cross referenced from the statement number references provided in the command. The watch command entered by a user is parsed by the expression evaluator226that uses a break point table232(further discussed herein below with respect to FIG. to map the line number in the watch command to the actual physical storage address in memory212. The code interpreter228passes on the synchronization control point or break point information to the break point manager230, which in turn updates the break point table232. The code interpreter228runs a code program to control the break point manager230to set the control points. In some instances, the user may define these control points by referring to high-order language (HOL) references, such as, line or statement numbers or software object references, such as, a program or module name, from which the physical storage address may be cross referenced. After the control points are set, the user or programmer provides an input that resumes execution of the threaded program216. Execution of the program eventually results in an encounter of a control point, which causes a system exception. An interrupt handler, or similar means, passes information regarding the exception or interrupt to the break point manager230. The break point manager230references and updates the break point table232as required in order to track a break point where a variable within a critical section has been updated by a thread executing outside of the critical section. If such a break point is recognized, then the break point manager230triggers displaying of the break point by halting execution of the multi-threaded computer program. Further, the break point manager230also enables program execution to recommence after appropriate measures have been taken. In an embodiment, the break point manager230utilizes the debugger hook234in order to obtain debugger commands, for instance, for resuming execution of a program when a break point has halted program execution. The debugger hook234prompts the debug user interface224when required and, further, the debugger hook234utilizes the result buffer236to cache data for the debug user interface224.

Referring back toFIG. 1, as shown, one or more programmer or users, for instance, user1(reference numeral130) through user N (reference numeral140) may access the debugging server or system104, which has deployed thereon the critical section watch tool120, which implements the invention. The critical section watch tool or program120is run on the server104to debug a threaded program and, in particular, to monitor changes to a variable within the critical section that occur as a result of threads running outside of the critical section. The debugger program118running on the debugging server or system104is configured to invoke the critical section watch tool120for monitor changes to a variable within the critical section that occur as a result of threads running outside of the critical section.

Further, as shown inFIG. 1, the debugging server or system104(which has implemented thereon the critical section watch tool120) is shown in communication with a general storage or file system122, which stores, in an embodiment, critical section watch table(s)126, critical section record list table(s)127and breakpoint table(s)128. In particular, a user1(reference numeral130through user N, reference numeral140) accesses the debugging server or system104over a network via interfaces (e.g., web browsers) loaded on a client, for example, a personal computer, a laptop, a handheld device, etc. In the case of the latter, the network can be any type of network such as the Internet, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), etc. In any event, communication with infrastructure102could occur via a direct hardwired connection (e.g., serial port), or via an addressable connection that may utilize any combination of wireline and/or wireless transmission methods. Moreover, conventional network connectivity, such as Token Ring, Ethernet, WiFi or other conventional communications standards could be used. Still yet, connectivity could be provided by conventional TCP/IP sockets-based protocol. In this instance, the parties could utilize an Internet service provider to establish connectivity to infrastructure102. It should be understood that under the present invention, infrastructure102could be owned and/or operated by a party such as a third-party provider148, or by an independent entity. Regardless, use of infrastructure102and the teachings described herein could be offered to the parties on a subscription or fee-basis. In either scenario, an administrator142could support and configure infrastructure102, for instance, upgrading the critical section watch tool120in the debugging server or system104.

The debugging system or server104is further shown to include a bus110, and input/output (I/O) interfaces108. Further, the server104is shown in communication with external I/O devices/resources124and storage system122. In general, processing unit106executes computer program code, such as, the operating system114, the threaded programs116, the debugger118and the critical section watch tool120. While executing computer program code, the processing unit106can read and/or write data to/from memory112, storage system122, and/or I/O interfaces108. For instance, in one embodiment, the critical section watch tool120stores one or more critical section watch table(s)126in storage122. Similarly, the critical section watch tool120stores any record list table(s)127and break point table(s)128in local storage122. Alternatively, the watch table(s)126, record list table(s)127and break point table(s) may be stored in a separate storage within the system104. Bus110provides a communication link between each of the components in computer system100, such that information can be communicated within the infrastructure102. External devices124can comprise any devices (e.g., keyboard, pointing device, display, etc.) that enable a user to interact with computer system100and/or any devices (e.g., network card, modem, etc.) that enable server104to communicate with one or more other computing devices. Computer infrastructure102is only illustrative of various types of computer infrastructures for implementing the invention. For example, in an embodiment shown, computer infrastructure102comprises two or more computing devices (e.g., a server cluster) that communicate over a network to perform the various process steps of the invention. Moreover, computer system100is only representative of various possible computer systems that can include numerous combinations of hardware. To this extent, in other embodiments, computer system100can comprise any specific purpose computing article of manufacture comprising hardware and/or computer program code for performing specific functions, any computing article of manufacture that comprises a combination of specific purpose and general purpose hardware/software, or the like. In each case, the program code and hardware can be created using standard programming and engineering techniques, respectively. Moreover, processing unit106may comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g., on a client and server.

Similarly, memory112and/or storage system122can comprise any combination of various types of computer-readable data storage that reside at one or more physical locations. Further, I/O interfaces108can comprise any system for exchanging information with one or more external devices124. Still further, it is understood that one or more additional components (e.g., system software, math co-processing unit, etc.) not shown inFIG. 1can be included in computer system100. However, if computer system100comprises a handheld device or the like, it is understood that one or more external devices124(e.g., a display) and/or storage system(s)122could be contained within computer system104, and not externally as shown. Storage system122can be any type of system (e.g., a database) capable of providing computer-readable storage for information under the present invention. To this extent, storage system122could include one or more computer-readable storage devices, such as a magnetic disk drive or an optical disk drive. In another embodiment, storage system122includes data distributed across, for example, a local area network (LAN), wide area network (WAN) or a storage area network (SAN) (not shown). Although not shown, additional components, such as cache memory, communication systems, system software, etc., may be incorporated into computer system100. The terms “computer-readable storage device” and “computer-readable storage devices” do not include signal propagation media.

Accordingly, as shown inFIG. 1, there is illustrated a system100that provides a computer program product for monitoring changes to a variable that occur outside of the critical section of a threaded program, in accordance with an embodiment of the present invention. The computer program product comprises a computer readable or computer-usable storage medium, which provides program code, namely, the critical section watch tool120, for use by or in connection with a computer or any instruction execution system. The critical section watch tool or program120can be loaded into computer system104from a computer readable media146, such as, a magnetic tape or disk, optical media, DVD, memory stick, semiconductor memory, etc. or downloaded from the Internet via a TCP/IP adapter card144.

Reference is now made toFIG. 3, reference numeral300, which depicts a schematic block system diagram illustrating one embodiment of a computer system300, such as, a server that has deployed thereon or is coupled to a system that has deployed thereon a critical section watch tool or code320configured to automatically monitor changes to a critical section of a threaded program, such that, only updates or changes to a variable within the critical section that occur outside of the critical section will trigger the watch. As shown inFIG. 3, the server or system300comprises a central processing unit (CPU)304, a local storage device302, a user interface306, a network interface308and a memory310. The CPU304is configured generally to execute operations within the system/server300, such as, the threaded program312and the debugger program314, which in an embodiment, are stored in memory310. The network interface306is configured, in one embodiment, to facilitate network communications of the system300over a communications channel of a network. In one embodiment, as shown inFIG. 3, the critical section watch tool320comprises a logic unit that contains a plurality of modules configured to functionally execute the necessary steps for automatically monitoring changes to a variable within a critical section of a threaded program, such that only updates to the variable that occur outside of the critical section of the threaded program will trigger displaying any watches triggered responsive to updates to the variable. In particular, the critical section watch tool or code320comprises a critical section variable selection module322, a critical section selection module324, a critical section break point module326, a critical section watch module328, a critical section record list module330, a critical section thread update module332, a thread execution module334, and a communications module342.

Referring toFIG. 3, the critical section variable selection module322of the critical section watch tool or code320is configured to select a variable within a critical section that is of interest to a user or programmer. As such, the user or programmer selects or chooses a variable within the critical section that is to be monitored by the critical section watch tool320. The critical section identification module324is configured to select or establish or identify a starting line of a critical section and an ending line of the critical section. The critical section break point module326is configured to set special internal break points, such that, a debugger can identify when a particular thread is executing within the critical section and can ignore any watches produced as a result of the particular thread executing within the critical section. In an embodiment, the critical section break point module326is configured to display break point information in break point table(s)318, which in an embodiment, are stored by the critical section watch tool320in the local storage302. Break point table(s) are discussed further herein below with respect toFIG. 5. The critical section watch module328is configured to establish a watch table that lists all the watches produced by threads executing within the critical section, as explained further herein below with respect toFIG. 3. In an embodiment, the critical section watch tool320stores any watch table(s)316created by the critical section watch module328in a local storage, such as, storage302. The critical section record list module330is configured to establish a record list table317(shown in storage302) that lists details of one or more critical sections being monitored, as explained further herein below with respect toFIG. 4. In an embodiment, the critical section watch tool320stores any record list table(s)317created by the critical section watch module328in the local storage302. The critical section thread update module332is configured to monitor changes to a variable that occur as a result of a thread executing outside of the critical section of the threaded program. The thread execution module334is configured to start and stop execution of a thread within the critical section when debugging the threaded program. The communications module336is configured to permit communication between the various modules of the critical section watch tool or code320and other systems, such as, the storage302and memory310. In an embodiment, the storage module336stores updated data pertaining to services, service providers, consumers and/or client devices in a storage system, such as, the storage302.

Reference is now made toFIGS. 4 through 6, which depict various embodiments of the invention for monitoring changes to a variable that occur outside of the critical section of a threaded program, in accordance with an embodiment of the invention. Turning toFIG. 4, reference numeral400depicts a data structure for a critical section watch table for monitoring changes to a variable within a critical section caused by threads executing outside of the critical section. In an embodiment, as shown inFIG. 4, the critical section watch table includes a “watch number (#)” column (reference numeral402), an “address” column (reference numeral404), a “length” column (reference numeral406and a “critical section number (#)” column (reference numeral408). In particular, the critical section watch table400shows two critical section watches that are listed, namely watch number1(row420) and watch number2(row430). In particular, as shown in the critical section number column (reference numeral408), watch number1has an address of 75D13200 listed in the address column404, whereas, watch number2has an address of 75D13100 listed in the address column404. The address in the address column404represents the physical storage location for the instruction. Further, watch number1identifies the length of the watch number1section being watched, which in this case is 20 bytes (length column406), whereas, watch number2lists the length of the watch number2section being watched as 4 bytes. Further, table400shows that watch number1has a critical section number value of “0” (column408), whereas, watch number2has a critical section number value of “1”. In an embodiment, the numeric value listed in the critical section number column408of table400connects a watch table entry listed for a threaded program being debugged inFIG. 4to an entry for the threaded program being debugged in the record list table ofFIG. 5. Accordingly, as shown inFIGS. 4 and 5, the entry in row430is related to the entry in row530given that the critical section numeric values are the same, namely, having a critical section # value of 1. As such, watch #1having a critical section #0(row430inFIG. 4) is not a critical section watch given that there is no corresponding entry for the critical section #0in the Record List table500ofFIG. 5.

Turning toFIG. 5, reference numeral500depicts a data structure for a critical record list table for monitoring changes to a variable within a critical section caused by threads executing outside of the critical section. In an embodiment, as shown inFIG. 5, the critical section record list table500includes a “critical section number (#)” column (reference numeral502), a “module” column (reference numeral504), a “start” column (reference numeral506), an “end” column (reference numeral508) and a “thread list” column (reference numeral510). In an embodiment, as shown inFIG. 5, the critical section number column502, shows that for a critical section number1the module is listed or identified as “Foo” (column504). Further, the module Foo is shown to have a start line (column506) that begins at line23and an end line (column508) that ends with line41. Further, the thread list column510provides an entry for each thread that is active within the critical section of a threaded program. In particular, the thread list column510further provides a “thread number (#)” (column512) of the thread that is executing within the critical section of a threaded program. In the example shown in column512, the thread number is thread3253. As such, while a thread is within the critical section, the thread will be listed in the record list column, as described further herein below with respect toFIG. 7. Also, given that multiple threads can be running through the same critical section of code, the arrow in the Next column514refers to the fact that information can be saved on several threads at once, using the threads listed in the thread list column510.

Turning toFIG. 6, reference numeral600depicts a data structure for a critical section break point table for monitoring changes to a variable within a critical section caused by threads executing outside of the critical section, in accordance with an embodiment of the invention. As discussed herein above, a user may define break points or control points by referring to line numbers or statement numbers or by referring to software object references, such as, a program or module name, from which the physical storage address may be cross referenced. As shown inFIG. 6, the critical section break point table600includes an “address” column (reference numeral602), a “line number” column (reference numeral604), a “saved op code” column (reference numeral606), a “Start?” column (reference numeral608), an “End?” column (reference numeral610) and a “critical section number (#)” column (reference numeral612). As shown in row620, an address in the address column602has a value of 712498A1, and is associated with line number23(line number column604). The address shown in the address column602represents the physical storage location for the instruction on line23. Further, the saved op code column606, which stores the original op code or instruction replaced in the threaded program has a value of “LOAD”. It is understood that the LOAD op code or instruction is exemplary and that the instruction could be any other instruction. In embodiment, the op code or instruction LOAD sets up access to read the specific data at the specified address. The “Start?” column608shows a value of “yes”, whereas the End? column610shows a value of “no”. Further, the critical section number (#) column612shows the value of “1”, indicating that this is a critical section watch, as listed in the critical section record list inFIG. 5. Similarly, row630shows an address in the address column602has a value of 712598B2, and is associated with line number41(line number column604). Further, the saved op code column606has a value of “STR”. It is understood that the STR op code or instruction is exemplary and that the instruction could be any other instruction. In an embodiment, the saved op code column stores the original op code or instruction that is replaced in the threaded program. In an embodiment, the op code STR writes the specific data loaded to the specified address. The “Start?” column608shows a value of “no”, whereas the End? column610shows a value of “yes”. Further, the critical section number (#) column612shows the value of “1”, indicating that this is a critical section watch, as listed in the critical section record list ofFIG. 5. Furthermore, row640shows an address in the address column602has a value of 722698D2, and is associated with line number92(line number column604). Further, the saved op code column606has a value of “STR”. In an embodiment, the op code STR writes the specific data loaded to the specified address. The “Start?” column608shows a value of “no”, and the End? column610also shows a value of “no”. Further, the critical section number (#) column612shows the value of “0”, indicating that this is not a critical section watch listed in the critical section record list ofFIG. 5. In an embodiment, a break point is implemented by replacing a valid op code or instruction, which is saved by the system, with an invalid op code or instruction that will cause the system to trap. As such, the debugger needs the saved op code or instruction for restoring the op code or instruction that was replaced when the start break point is hit and in order to restore the saved op code when the debugger program resumes control by emulating the op code after the debugger program hits the end break point. It is understood that the tables400through600are merely for illustration purposes and that modifications can be made to the tables for providing fewer or more types of data. In addition, this information could be contained in one or more data structures of various compositions.

In another embodiment, the invention provides a method for monitoring changes to a variable within a critical section that occur due to threads executing outside the critical section, using a critical section watch tool, in accordance with an embodiment of the present invention. Turning toFIG. 7, reference numeral700depicts a method carried out by a debugger that includes an add-on critical section watch tool or debugging tool for monitoring changes to a variable within a critical section of a threaded program, as described herein above. As such, the critical section watch tool coupled to the debugger gets an event in step702. The critical section watch tool determines in step704whether or not the event is to set a critical section watch. If the critical section watch tool determines that the event is to set a critical section watch (Yes branch), then the critical section watch tool sets in step706the start break point and the end break point. Further, in step708, the critical section watch tool adds the critical section record to a record list (as discussed herein above with respect toFIG. 5) and further establishes a watch associated with the critical section, which in an embodiment, is tracked in a watch table (as discussed herein above with respect toFIG. 4). The critical section watch tool returns back to step702and gets another event. Referring back to step704, if the critical section watch tool determines that the event is not to set a critical section watch (No branch), then the critical section watch tool determines in step710whether or not a start break point was hit or encountered. If the critical section watch tool determines in step710that a start break point was encountered, then the critical section watch tool adds in step712the thread executing within the critical section to a thread list associated with that critical section (the critical section record list table shown inFIG. 5) and the critical section watch tool resumes execution of the threaded program in step714, and returns to step702. Accordingly, when a break point is hit, the debugger records the thread that has hit a start break point by adding it to the list shown inFIG. 5, thus, getting control of the debugger, and by removing the break point when an end break point is encountered. However, back in step710, if the critical section watch tool determines that a start break point was not encountered, then the critical section watch tool determines in step716whether or not an end break point was hit or encountered. If the critical section watch tool determines in step716that an end break point was encountered (yes branch), then the critical section watch tool removes in step720the thread from the thread list associated with that critical section. The critical section watch tool resumes execution in step722, and returns to step702. However, in step716, if the critical section watch tool determines that an end break point was not encountered, then the critical section watch tool determines in step724whether or not a watch fired. If the critical section watch tool determines in step718that a watch did fire, then the critical section watch tool further determines in step726whether or not the watch is associated with a critical section listed in the watch table. If the critical section watch tool determines in step726that the watch is not associated with a critical section, then the critical section watch tool processes in step732the watch as if a normal watch, that is, the watch is presented or displayed to the debugger user and the process returns to step702. On the other hand, if the critical section watch tool determines in step726that the watch is associated with a critical section, then the critical section watch tool further determines in step734whether or not the watch is currently within the critical section. If the critical section watch tool determines in step734that the watch is currently within the critical section (yes branch), then the critical section watch tool resumes execution in step736, that is, the watch is ignored, and the process returns to step702. However, if the critical section watch tool determines in step734that the watch is not currently within the critical section (no branch), then the critical section watch tool processes in step738the watch as a normal watch, allowing the watch to fire and bringing the watch to the debugger user's attention. The process returns to step702. Going back to step718, if the critical section watch tool determines that a watch did not fire, then the critical section watch tool further determines in step724whether or not the event is to update the threads display in the critical section record list inFIG. 5. If the critical section watch tool determines in step724that the event is to update the threads display, then the critical section watch tool updates in step728the display to contain each thread and highlights threads contained in the critical section's thread list, and the process returns to step702. However, if the critical section watch tool determines in step724that the event is not to update the threads display, that is, the event pertains to other events unrelated to the monitoring of changes to data in a critical section, then the critical section watch tool handles in step730these other events and the process returns to step702.

Accordingly, the critical section watch tool coupled to the debugger is used to selectively monitor changes to a protected variable that occur outside of the critical section, while the critical section is active. A user or programmer sets a watch for monitoring a variable by selecting the protected variable to watch and then selecting the lines that establish the start and end break points of the critical section. As such, the critical section watch tool coupled to the debugger monitors the variable by first determining whether or not a thread has executed the line selected to be the start line of the critical section and then by further determining that the thread has not yet executed the critical section end line, thus, any changes to the protected variable can be ignored. Thus, only changes to the protected variable that occur outside of the critical section will trigger or fire the watch, increasing the effectiveness of the watch command. Watches will fire as values are stored to that variable, but the program will determine whether or not the thread is within the critical section and, if the thread is, it will not tell the user about the change to the variable and will just let the program resume. In addition, when a watch fires, it will not only report the variable and location of the change, but will also highlight the threads that are currently in the critical section on the threads display in the threads list.