1. A machine readable medium including program code stored thereon which, when executed by a machine, causes the machine to perform the operations of:
detecting a non-transactional write operation in code including transactional operations, the non-transactional write operation, when executed, to write to a memory location;
inserting a first strong atomicity operation, when executed, to determine if a processing element to execute the non-transactional write operation owns the memory location; and
inserting a second strong atomicity operation to be executed in response to determining the processing element does not own the memory location, the second strong atomicity operation, when executed, to vector execution to a plurality of write barrier operations, wherein the second strong atomicity operation is not to be executed in response to determining the processing element owns the memory location.
2. The machine readable medium of claim 1, wherein the program code which, when executed by a machine, further causes the machine to perform the operations of:
inserting the plurality of write barrier operations, and wherein the plurality of write barrier operations include: a first write barrier operation, when executed, to acquire the transaction record for the processing element, the first write barrier operation including a call to a function.
3. The machine readable medium of claim 2, wherein the function includes:
a first operation, when executed, to acquire the transaction record;
a second operation, when executed, to determine if a write buffer is full;
a third operation, when executed, to flush the write buffer in response to determining the write buffer is full; and
a fourth operation, when executed, to record the transaction record in the write buffer.
4. The machine readable medium of claim 3, wherein the third operation, when executed, to flush the write buffer includes releasing ownership of a plurality of transaction records held in the write buffer, and wherein the fourth operation, when executed, to record the transaction record in the write buffer includes storing a transaction value and an address associated with the memory location in an entry of the write buffer.
5. A method comprising:
determining if a lock associated with a memory location is owned by a processing element;
in response to determining the lock is not owned by the processing element:
writing an entry to a buffer, the entry including a value of the lock and an address associated with the memory location, and
acquiring ownership of the lock for the processing element; and
executing a non-transactional write operation with the processing element in response to the lock being owned by the processing element.
6. The method of claim 5, wherein determining if a lock associated with a memory location is owned by a processing element comprises determining the value of the lock associated with the memory location and comparing the value of the lock to a processing element value to determine if the lock value indicates the lock associated with the memory location is owned by the processing element.
7. The method of claim 5, further comprising determining the buffer is full; and flushing the write buffer.
8. The method of claim 7, wherein flushing the write buffer comprises flushing a plurality of entries of the buffer and releasing a plurality of locks referenced in the plurality of entries in response to flushing the plurality of entries.
9. The method of claim 15, wherein determining the buffer is full is also in response to determining the lock is not owned by the processing element, and wherein determining the buffer is full comprises polling the buffer to determine if the buffer is full.
10. The method of claim 7, wherein determining the buffer is full comprises handling an asynchronously generated interrupt in response to filling the buffer to determine the buffer is full.
11. A tangible machine readable medium including code, when executed by a machine, causes the machine to perform the operations of:
determining if a processing element owns a software transactional lock for an address associated with a data object before performing a non-transactional write operation;
executing a write barrier for the non-transactional write operation before performing the non-transactional write operation in response to determining the processing element does not own the software transactional lock for the address associated with the data object; and
performing the non-transactional write operation without executing the write barrier in response to determining the processing element owns the software transactional lock for the address associated with the data object.
12. The machine readable medium of claim 11, wherein executing the write barrier comprises:
logging an un-owned value of the software transactional lock and the address in a storage area; and
acquiring the software transactional lock.
13. The machine readable medium of claim 12, wherein acquiring the software transactional lock includes updating the software transactional lock from the un-owned value to an owned value.
14. The machine readable medium of claim 13, wherein the code, when executed by the machine, further causes the machine to perform the operations of: not returning the software transactional lock from the owned value to the un-owned value until a non-transactional lock release event is encountered.
15. The machine readable medium of claim 14, wherein the non-transactional lock release event includes determining a lock release storage element holds a lock release value, and wherein the lock release storage element is to be updated by a second processing element to the lock release value in response to the second processing element attempting to update the transaction record to hold a second owned value to indicate the second processing element owns the memory location when the transaction record holds the first owned value to indicate the processing element owns the memory location.
16. The machine readable medium of claim 14, wherein the storage area includes a write buffer, and wherein the lock release event is selected from a group consisting of overflowing the write buffer, starting execution of a transaction, and attempting to acquire the software transactional lock with a second processing element when the software transactional lock holds the owned value responsive to a first processing element updating the software transactional lock from the un-owned value to the owned value.
17. The machine readable medium of claim 14, wherein the storage area includes a write buffer, and wherein the write buffer is to be flushed in response to encountering the non-transactional lock release event.
18. A method comprising
determining if a processing element owns a software transactional lock for an address associated with a data object before performing a non-transactional write operation;
executing a write barrier for the non-transactional write operation before performing the non-transactional write operation in response to determining the processing element does not own the software transactional lock for the address associated with the data object; and
performing the non-transactional write operation without executing the write barrier in response to determining the processing element owns the software transactional lock for the address associated with the data object.
19. The method of claim 18, wherein executing the write barrier comprises:
logging an un-owned value of the software transactional lock and the address in a storage area; and
acquiring the software transactional lock.
20. The method of claim 19, wherein acquiring the software transactional lock includes updating the software transactional lock from the un-owned value to an owned value.
21. The method of claim 20, further comprising: not returning the software transactional lock from the owned value to the un-owned value until a non-transactional lock release event is encountered.
22. The method of claim 21, wherein the non-transactional lock release event includes determining a lock release storage element holds a lock release value, and wherein the lock release storage element is to be updated by a second processing element to the lock release value in response to the second processing element attempting to update the transaction record to hold a second owned value to indicate the second processing element owns the memory location when the transaction record holds the first owned value to indicate the processing element owns the memory location.
23. The method of claim 21, wherein the storage area includes a write buffer, and wherein the lock release event is selected from a group consisting of overflowing the write buffer, starting execution of a transaction, and attempting to acquire the software transactional lock with a second processing element when the software transactional lock holds the owned value responsive to a first processing element updating the software transactional lock from the un-owned value to the owned value.
24. The method of claim 21, wherein the storage area includes a write buffer, and wherein the write buffer is to be flushed in response to encountering the non-transactional lock release event.
The claims below are in addition to those above.
All refrences to claim(s) which appear below refer to the numbering after this setence.
1. A computing system for parsing a text file to retrieve desired data from the text file, the computing system comprising:
a defining module configured for defining a tree pattern based on the text file, and defining a plurality of character string patterns to identify the desired data;
a loading module configured for loading the text file into a storage system;
a parsing module configured for determining a tree structure corresponding to the text file according to the tree pattern, and retrieving the desired data from the text file according to the tree structure corresponding to the text file and the character string patterns; and
an outputting module configured for outputting the retrieved desired data into the storage system.
2. The system of claim 1, wherein the tree pattern is defined by using extensible markup language (XML), and the character string patterns are defined by using regular expressions.
3. The system of claim 1, wherein the loading module loads the text file into an array, and the parsing module parses the text file in the array.
4. The system of claim 1, wherein the outputting module outputs the retrieved desired data in a predetermined data format.
5. The system of claim 4, wherein the predetermined data format is an XML format.
6. A computer-implemented method for parsing a text file, the method comprising:
defining a tree pattern based on the text file, and defining a plurality of character string patterns to identify the desired data;
loading the text file into a storage system;
determining a tree structure corresponding to the text file according to the tree pattern, and retrieving the desired data from the text file according to the tree structure corresponding to the text file and the character string patterns; and
outputting the retrieved desired data into the storage system.
7. The method of claim 6, wherein the tree pattern is defined by using extensible markup language (XML), and the character string patterns are defined by using regular expressions.
8. The method of claim 6, wherein the text file is loaded into an array.
9. The method of claim 8, wherein the retrieved desired data are output in a predetermined data format.
10. The method of claim 9, wherein the predetermined data format is an XML format.
11. A computer-readable medium having stored thereon instructions that, when executed by a computerized device, cause the computerized device to execute a computer-implemented method comprising:
defining a tree pattern based on the text file, and defining a plurality of character string patterns to identify the desired data;
loading the text file into a storage system;
determining a tree structure corresponding to the text file according to the tree pattern, and retrieving the desired data from the text file according to the tree structure corresponding to the text file and the character string patterns; and
outputting the retrieved desired data into the storage system.
12. The medium of claim 11, wherein the tree pattern is defined by using extensible markup language (XML), and the character string patterns are defined by using regular expressions.
13. The medium of claim 11, wherein the text file is loaded into an array.
14. The medium of claim 11, wherein the retrieved desired data are output in a predetermined data format.
15. The medium of claim 14, wherein the predetermined data format is an XML format.