Steadily over time computers have become much more powerful, with more processing power and memory to handle advanced operations. This trend has recently shifted away from a focus on ever-increasing single-processor clock rates and towards an increase in the number of processors available in a single computer. Software developers want to take advantage of improvements in computer processing power, enabling their software programs to be executed faster as new hardware is adopted. With the new hardware trends, however, this requires a different approach: developers must arrange for one or more tasks of a particular software program to be executed “concurrently” (sometimes called “in parallel”), so that the same logical operation can utilize many processors at one time, and deliver better performance as more processors are added to the computers on which such software runs.
Transactional memory is designed to ease development of concurrent programs by providing atomicity and isolation to regions of program code. Transactional memory (TM) is a concurrency control mechanism analogous to database transactions for controlling access to shared memory in concurrent computing. A transaction in the context of transactional memory is a piece of code that executes a series of reads and writes to shared memory. TM is used as an alternative to traditional locking mechanisms. TM allows concurrent programs to be written more simply. A transaction specifies a sequence of code that is supposed to execute as if it were executing in isolation. This illusion of isolation is achieved by fine-grained locking of objects, and by executing in a mode that allows the effects of the transaction to be rolled back if the transaction is discovered to be in conflict with some other transaction. We say that a data access is “transacted” if the access is protected by these locking and rollback mechanisms
As transactional memory programming models are deployed, programmers will begin to experience performance problems around the use of transactions. Transactional semantics cause code sequences to experience conflicts with one another, leading to the need to re-execute code sequences to resolve the conflicts. This re-execution of code hurts performance in the form of lower scalability and higher energy consumption and must be minimized. In other words, the software must be designed to minimize the occurrence of transactional conflicts. The problem, however, is that existing debugging systems do not support the ability to easily diagnose, discover, and correct performance and correctness issues related to memory transactions.
A debugger for programs running under a transactional memory system detects when a conflict occurs on at least one conflictpoint that was set in the particular program. Information related to the detected conflict, such as transactional state of pending transaction, transactional state of transactions and/or other related details independently of a conflict can be displayed. For example, a conflictpoint can be assigned to one or more regions of source code in one or more transactions in the particular program and/or a particular variable in the particular program. When running the particular program in a debug mode, execution is stopped if a conflict occurs on any of the conflictpoints.
This Summary was provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope is thereby intended. Any alterations and further modifications in the described embodiments, and any further applications of the principles as described herein are contemplated as would normally occur to one skilled in the art.
The system may be described in the general context as a debugger for transactions in a program operating under a transactional memory system, but the system also serves other purposes in addition to these. In one implementation, one or more of the techniques described herein can be implemented as features within a software development program such as MICROSOFT® VISUAL STUDIO®, or from any other type of program or service that allows transactions in programs operating under a transactional memory system to be debugged.
As shown in
Additionally, device 100 may also have additional features/functionality. For example, device 100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computing device 100 includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115. Device 100 may also have input device(s) 112 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 111 such as a display, speakers, printer, etc. may also be included. These devices are well known in the art and need not be discussed at length here. In one implementation, computing device 100 includes transactional debugger application 200. Transactional debugger application 200 will be described in further detail in
Turning now to
Transactional debugger application 200 includes program logic 204, which is responsible for carrying out some or all of the techniques described herein. Program logic 204 includes logic for providing a transactional debugger application for debugging programs running under a transactional memory system 206; logic for receiving input from a user or otherwise to assign one or more conflictpoints to particular program operating under the transactional memory system 208; logic for running the particular program in debug mode 210; logic for detecting when a conflict occurs at one of the conflictpoints and then stopping program execution 212; logic for providing a graphical user interface that displays transactional state, variables, and/or other information related to the conflict 214; logic for optionally allowing the user to customize various settings for the one or more conflictpoints to specify when conflicts should be detected 216; and other logic for operating the application 220. In one implementation, program logic 204 is operable to be called programmatically from another program, such as using a single call to a procedure in program logic 204.
Turning now to
Turning now to
Turning now to
Turning now to
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. All equivalents, changes, and modifications that come within the spirit of the implementations as described herein and/or by the following claims are desired to be protected.
For example, a person of ordinary skill in the computer software art will recognize that the client and/or server arrangements, user interface screen content, and/or data layouts as described in the examples discussed herein could be organized differently on one or more computers to include fewer or additional options or features than as portrayed in the examples.
This application claims priority to and is a continuation of co-pending U.S. patent application Ser. No. 11/820,284, entitled “Transactional Debugger for a Transactional Memory System and Detecting Conflicts” and filed Jun. 19, 2007, which is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5157777 | Lai et al. | Oct 1992 | A |
5317740 | Sites | May 1994 | A |
5774717 | Porcaro | Jun 1998 | A |
5854924 | Rickel et al. | Dec 1998 | A |
5999987 | O'Farrell et al. | Dec 1999 | A |
6085035 | Ungar | Jul 2000 | A |
6138269 | Ball | Oct 2000 | A |
6226787 | Serra et al. | May 2001 | B1 |
6324683 | Fuh et al. | Nov 2001 | B1 |
6467052 | Kaler et al. | Oct 2002 | B1 |
6519766 | Barritz et al. | Feb 2003 | B1 |
6552585 | Poullet | Apr 2003 | B2 |
6553384 | Frey et al. | Apr 2003 | B1 |
6654760 | Baskins et al. | Nov 2003 | B2 |
6698013 | Bertero et al. | Feb 2004 | B1 |
6826757 | Steele, Jr. et al. | Nov 2004 | B2 |
6954923 | Yates et al. | Oct 2005 | B1 |
6959405 | Hite et al. | Oct 2005 | B2 |
7013456 | Van Dyke et al. | Mar 2006 | B1 |
7058954 | Wolrath et al. | Jun 2006 | B1 |
7076784 | Russell et al. | Jul 2006 | B1 |
7254806 | Yates et al. | Aug 2007 | B1 |
7316005 | Qadeer et al. | Jan 2008 | B2 |
7716645 | Dolby et al. | May 2010 | B2 |
7721263 | Swoboda | May 2010 | B2 |
7739669 | Swoboda | Jun 2010 | B2 |
7752605 | Qadeer et al. | Jul 2010 | B2 |
7770153 | Chilimbi et al. | Aug 2010 | B2 |
7784035 | Kahlon et al. | Aug 2010 | B2 |
7818723 | AliKacem et al. | Oct 2010 | B2 |
7840947 | Lev et al. | Nov 2010 | B2 |
7849446 | Lev et al. | Dec 2010 | B2 |
7921407 | Damron et al. | Apr 2011 | B2 |
8001539 | Mitchell | Aug 2011 | B2 |
8141058 | Berg et al. | Mar 2012 | B2 |
8166459 | Suenbuel | Apr 2012 | B2 |
8307346 | Lev et al. | Nov 2012 | B2 |
8423966 | Dolby et al. | Apr 2013 | B2 |
8443341 | Berg et al. | May 2013 | B2 |
8453120 | Ceze et al. | May 2013 | B2 |
8468502 | Lui et al. | Jun 2013 | B2 |
8473921 | Taillefer et al. | Jun 2013 | B2 |
20040185876 | Groenendaal et al. | Sep 2004 | A1 |
Number | Date | Country |
---|---|---|
2239334 | Jun 1991 | GB |
Entry |
---|
DZyulkyarov et al, “Debugging Programs that use Atomic Blocks and Transactional Memory” ACM, pp. 57-66, 2010. |
Jacobi et al, “Transactional Memory Architecture and Implementation for IBM System Z”, IEEE, 25-26, 2012. |
McKechnie et al, “Debugging FPGA-based Packet Processing Systems through Transaction-level Communication-centric Monitoring”, ACM, pp. 126-136, 2009. |
Tang et al, “A Debug Probe for Concurrently Debugging Multiple Embedded Cores and Inter-Core Transactions in NoC-Based Systems”, IEEE, pp. 416-421, 2008. |
EP Application No. 08770335.01, Amendment mailed Mar. 19, 2013, 12 pages. |
EP Application No. 08770335.01, Extended European Search Report, mailed Aug. 22, 2012, 8 pages. |
Hassan Chafi, et al., “TAPE: A Transactional Application Profiling Environment”, ICS '05, 2005, 10 pages. |
Yossi Lev, et al., “Debugging with Transactional Memory”, 2006, 10 pages. |
Nancy J. Wahl et al., “A Paradigm for Distributed Debugging”, ACM 1992, 8 pages. |
Herlihy, Maurice et al., “Transactional Memory: Architectural Support for Lock-Free Data Structures”, ISCA '93 Proceedings of the 20th annual international symposium on computer architecture, ACM New York, NY, USA, 1993, 12 pages. |
Herlihy, et al., “Software Transactional Memory for Dynamic-Sized Data Structures,” Date: Jul. 13, 2003-Jul. 16, 2003, pp. 1-12. |
Shaughnessy, Managed Code Database Advantage for the Microsoft .NET Framework Platform, http://bdn1.borland.com/borcon2004/article/paper/0,1963,32236,00.html. |
International Search Report and Written Opinion Received for PCT Application No. PCT/US2008/06618, mailed on Dec. 30, 2008, 10 pages. |
U.S. Appl. No. 11/820,284, Non-Final Office Action mailed May 11, 2011, 20 pages. |
U.S. Appl. No. 11/820,284, Amendment filed Aug. 17, 2011, 14 pages. |
U.S. Appl. No. 11/820,284, Notice of Allowance mailed Sep. 28, 2011, 10 pages. |
Zamfir et al, “Execution synthesis a technique for automated software debugging”, ACM EuroSys, pp. 321-334, 2010. |
Aral et al, “Parasight: A high level debugger/profiler architecture for shared memory multiprocessors”, ACM pp. 131-139, 1988. |
Kingsbury, “Organizing processes and threads for debugging”, ACM PADTAD, pp. 21-26, 2007. |
Saha et al, “Architectural support for software transactional memory”, IEEE Micro, pp. 1-12, 2006. |
Chung et al, “ASF: AMD64 extension for lock free data structures and transactional memory”, IEEE, pp. 39-50, 2010. |
Zyulkyrov et al, “Debugging programs that use atomic block and transactional memory”, ACM PPoPP, pp. 57-66, 2010. |
Number | Date | Country | |
---|---|---|---|
20120084760 A1 | Apr 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11820284 | Jun 2007 | US |
Child | 13323921 | US |