WO2017058208A1

WO2017058208A1 - Multi-threaded application persistence

Info

Publication number: WO2017058208A1
Application number: PCT/US2015/053264
Authority: WO
Inventors: Indrajit Roy; Ching Hsiang Hsu; Helge BRUEGNER; Kimberly Keeton
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-09-30
Filing date: 2015-09-30
Publication date: 2017-04-06

Abstract

Examples herein involve persistence of multi-threaded applications. Examples involve generating application processes corresponding to threads of an application comprising multiple threads and identifying critical sections of the application based on the generated application processes. The application processes in the critical sections are executed in a sequential manner to facilitate reuse of persistent data of the application and shared data from the sequentially executed application processes are stored in a non-volatile memory.

Description

mULThTH EADED APPLICATION PERSlSTE C

BACKGROUND

[0001] Some computing systems use random access memory (RAM) devices as intermediary storage for relatively fast access to data that is also stored in long-term mass storage devices (e.g., magnetic memories, optical memories, flash memories, etc.). in this manner, computing systems can perform faster data accesses by copying data from the long-term mass storage devices to the intermediary RAM devices, and by accessing the data from the RAM devices.

[0002] Soiid~state memory devices for long-term storage include nonvolatile random access memory (NVRAM) such as phase-change RAM

(PCRAM), emristors, and spin-transfer torque random access memory (STT- RAM). NVRAM is a persistent memory system that maintains data stored therein even when power is removed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003J FIG. 1 is a block diagram of an example multi-threaded execution system including a multi-threaded application manager constructed in accordance with an aspect of this disclosure.

[0004J FIG. 2 is a block diagram of an example multi-threaded application manager that may be used to implement the multi-threaded application manager of FIG. 1 .

[0005] FIG. 3 is a block diagram of an example implementation of a multithreaded application executor that may be implemented by the example multithreaded application manager of FIG. 1 and/or 2. [0006] FIG. 4 is a block diagram of an example Implementation of a persistence manager that may be implemented by the multi-threaded application executor of FIG. 3.

[0007J FIG. 5 is a sequence diagram illustrating an example execution of a multi-threaded application by the example multi-threaded application executor of FIGS. 2 or 3.

[0008J FIG. 6 illustrates an example sequence of logging data changes from an executed application process by the persistence manager of FIG. 4 in a critical section over time.

[0009] FIG. 7 is a flowchart representative of example machine readable instructions that may be executed to implement a multi-application executor of FIG. 3.

[0010] FIG. 8 is a flowchart representative of an example portion of the example machine readable instructions of FIG. 7 to implement the multithreaded application executor of FIG. 3.

[0011] FIG. 9 is a flowchart representative of example machine readable instructions that may be executed to implement a restore manager of the multithreaded threaded application manager FIG. 2.

[0012] FIG. 10 is a block diagram of an example processor platform capable of executing the instructions of FIGS. 7, 8, and/or 9 to implement the multi-threaded application manager of FIG. 2 and/or components of the multithreaded application manager of FIGS. 3 and/or 4.

[0013] Wherever possible, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

[0014] Examples disclosed herein involve maintaining persistent data for multi-threaded applications. The persistent data may be used to restore multithreaded applications to an operational state after a stoppage event (e.g., a shutdown, a system crash, a fault/failure, an application crash, an application restart, etc.). [0015] Non-volatile memory technologies, such as memristor and phase- change memory, allow applications to persist data using common memory instructions. Accordingly, applications may achieve high-performance while still being crash tolerant (or able to restore a state of an application after a stoppage event). However, taking advantage of such technologies may involve substantial hardware changes or extensive application adjustments.

[0016] Examples herein provide persistence to existing multi-threaded applications (e.g., C/C++ applications). For example, execution of threads as application processes and logging data changes of the application processes enables use of the application process memory to buffer uncommitted changes. Accordingly, examples herein may restore a state of a multi-threaded application using just a redo log (rather than both a redo log and an undo log, like many other implementations).

[0017] Examples herein involve generating application processes corresponding to threads of an application comprising multiple threads;

identifying critical sections of the application based on the generated application processes; executing application processes in the critical sections in a sequential manner to facilitate reuse of persistent data of the application; and storing synchronized data such as from the sequentially executed application processes in a non-volatile memory.

[0018] FIG. 1 is a block diagram of an example multi-threaded execution system 100 including a multi-threaded application manager 1 10 implemented in accordance with examples herein. The example multi-threaded application manager 1 10 manages execution and recovery of multi-threaded applications using a memory 120 (e.g., a cache, a volatile memory, a non-volatile memory (e.g., NVRAM), etc.) and a non-volatile storage 130 (e.g., NVRAM, memristor, phase-change memory, SSDs, disks, etc.).

[0019] In examples herein, the multi-threaded application manager 1 10 may load multi-threaded applications or data from the non-volatile storage 130 into the memory 120 for execution. The multi-threaded application manager 1 10 persistently executes the multi-threaded applications in accordance with aspects of this disclosure such that a state of the multi-threaded application may be restored after a stoppage event that ceases execution of the multi-threaded application. Example stoppage events may include a crash of the system 100 (or a platform implementing the system 100, see FIG. 10), a shutdown of the system 100 (or a platform implementing the system 100, see FIG. 10), a crash of a multi-threaded application, etc. For example, during execution of a multithreaded application, if a stoppage event occurs, the multi-threaded application manager 1 10 may recover the state of the multi-threaded application at the time of the stoppage event using persistent data corresponding to the state of the multi-threaded application stored in the non-volatile storage 130. The persistent data of the multi-threaded application is stored and updated during execution of the multi-threaded application in accordance with examples herein.

[0020] FIG. 2 is a block diagram of an example multi-threaded application manager 1 10 that may be used to implement the multi-threaded application manager 1 10 of FIG. 1. The example multi-threaded application manager 1 10 of FIG. 2 includes a multi-threaded application executor 210 and a restore manager 220. The example multi-threaded application executor 210 of FIG. 2 executes multi-threaded applications in accordance with examples herein to provide persistent data corresponding to a state of a multi-threaded application during execution.

[0021]The restore manager 220 of FIG. 2 restores a state of the multithreaded application after a stoppage event that occurs during execution of the multi-threaded application, in examples herein, the restore manager 220 may determine that a restore of an application (e.g., a multi-threaded application) has been initiated. The example restore manager 220 may retrieve log data to restore a state of the application (e.g., a state of the application at the time of (or before) a stoppage event). The restore manager 220 may update shared data of the application using the log data that is generated in accordance with examples herein. For example, the restore manager 220 may read each log entry, find a corresponding memory page in the shared data, and apply the log entry to the memory page. Accordingly, the restore manager 220 of FIG. 2 may apply the log entry to the shared data of the multi-threaded application at a granularity of memory pages. Furthermore, the example restore manager may resume (or instruct the multi-threaded application executor 210 to resume) execution of an application from a state of the application (e.g., a previous state at the time of (or previous to) a stoppage event) using the shared data.

Accordingly, the restore manager 220 may retrieve log data generated in accordance with examples herein to restore an application (e.g., a multithreaded application) to a previous state (e.g., a state of the application at the time of a stoppage event) to resume execution of the application to recover (or restore) the application to a state of operation or execution at the time (or a prior to a time) of a stoppage event (e.g., a synchronization point of the multithreaded application).

[0022] FIG. 3 is a block diagram of an example application executor 210 that may be used to implement the application executor 210 of FIG. 2 in the multi-threaded application manager of FIG. 1. The example application executor 210 of FIG. 3 includes an application process generator 310, a critical section controller 320, an application process executor 330, and a persistence manager 340. In examples herein, application process generator 310 creates application processes from threads of multi-threaded applications that are to be executed. The application process executor 330 executes the application processes in accordance with instructions from the critical section controller 320, while the persistence manager 340 manages persistent data

corresponding to the state of the multi-threaded application during execution. Accordingly, the multi-threaded application executor 210 of FIG. 3 executes multi-threaded applications while providing persistent data that can be restored after a stoppage event. Thus, in examples herein, multi-threaded applications may be crash tolerant when executed by the multi-threaded application executor.

[0023]The example application process generator 210 of FIG. 2 generates application processes from threads of multi-threaded applications. As used herein, an application process generated from a thread includes a same or similar tasks of the respective thread, but the tasks are in a separate memory space (e.g., address space) from other processes or threads of the multi-threaded application (whereas tasks of threads are executed in a same or shared memory space). in examples herein, the application process generator 210 may perform a copy-on-write (e.g., via versioning) to create a private copy of the thread data in a separate address space of the memory 120.

Accordingly, the application process generator 210 may receive a multithreaded application, determine a number of threads of the multi-threaded application, and generate an appropriate number of application processes for the threads, each of which are in separate address spaces of the memory 120.

[0024] In examples herein, the application process executor 330 executes the application processes generated by the application process generator 310. The application process executor 330 may execute the application processes in parallel or in sequence depending on the types of the application processes. For example, the application process executor 330 may execute the application processes in parallel by default, but may then execute application process in a sequential manner (e.g., one by one, in a determined order, etc.) when a critical section (or a critical application process) of the multithreaded application is encountered. In examples herein, the critical section controller 320 may identify critical sections of the multi-threaded applications and instruct the application process executor 330 to execute the application processes in a sequential manner (see FIG. 5). The critical section controller 320 of FIG. 3 may identify the critical sections by detecting or identifying synchronization operations in the application processes. Example

synchronization operations may include lock operations, such as lock acquires and lock releases. During sequential execution of the synchronization operations, the persistence manager 340 ensures that persistent data corresponding to the state of the multi-threaded application is stored.

[0025] The example persistence manager 340 monitors execution of the application processes by tracking, logging, and synchronizing updated data during execution of the application processes. For example, for each application process executed during a critical section of the multi-threaded application, the persistence manager 340 may log data changes to a log entry of a log, flush the log entry to the non-volatile storage 130, and merge the updated data with a shared data of the multi-threaded application. The persistence manager 340 stores shared data from (sequentially) executed application processes in the non-volatile storage 130, As further discussed below in connection with FIG. 4, persistence of the application data may be achieved using the log and flushed log entry in the event that a stoppage event occurs during the critical section. Using the flushed log entries and merged update data from the non-volatile storage 130, the restore manager 220 may return the executed multi-threaded application to a previous consistent state prior to the stoppage event (e.g., the state of the application at the time (or just prior to the time) of the stoppage event).

[0026] Accordingly, the multi-threaded application executor 210 of FIG. 3 provides for execution of multi-threaded application while maintaining persistent data to enable restoration from a stoppage event. Thus, application execution by the multi-threaded application executor 210 may be fault (or shutdown, or restart) tolerant as the state of the multi-threaded application may be restored (by the restore manager 220) if the stoppage event occurs during execution of the multi-threaded application.

[0027] FIG. 4 is a block diagram of an example persistence manager 340 that may be used to implement the example persistence manager 340 of FIG. 3 in the multi-threaded application executor 210 of FIG. 2. The example persistence manager 340 of FIG. 4 includes a logger 410, a log fiusher 420, and an update merger 430. In examples herein, the logger 410 logs changed data for executed application processes to an entry of a log, the log fiusher 420 flushes the logged entry to the non-volatile storage 130, and the update merger 430 merges the changed data with shared data of the executed multi-threaded application.

[0028]The example logger 410 of FIG. 4 maintains log entries in a log that stores data changes resulting from executing application processes of a multi-threaded application. The example logger 410 may maintain the log in the memory 120 (e.g., in a cache) used to execute the multi-threaded application. In examples herein, the logger 410 logs the data changes during execution of application processes in critical sections of the multi-threaded application. In some examples, the logger 410 logs data changes outside of critical sections of the multi-threaded application. The logger 410 may use synchronization points of synchronization operations, such as lock acquire and lock release operations, to determine when to log the data changes. For example, the logger 410 may log data changes of an executed process application that occur between a lock acquire of the application process and a lock release of the application process after the lock release occurs. In some examples, for nested locks in which an outer lock operation includes an inner lock operation, the logger 410 may wait until the outer lock operation is complete before logging the data changes of the inner lock operation. As such, the logger 410 treats nested locks as a single lock operation that is to be completed, rather than individual lock operations.

[0029]The example log fiusher 420 of FIG. 4 flushes the log entries from the log to the non-volatile storage 130. As mentioned above, the log entries store recent data changes to the multi-threaded application. Accordingly, the flushed log entries include the recent data changes and are stored in persistent memory and can be retrieved and restored after stoppage event. The example flushed log entries may be stored in a restore memory space (e.g., within the non-volatile storage 130) that is accessible by the restore manager 220.

[0030] The update merger 430 of FIG. 4 merges the data changes with shared data of the multi-threaded application. The example shared data (or at least a copy of the shared data) may be stored in a shared memory state or shared memory space of the memory 120. Accordingly, the shared memory data may be lost in the event of a stoppage event during execution of the multithreaded application (though the log entries in the non-volatile storage 130 maintain persistence of that data). In examples herein, for each executed application process of the multi-threaded application, the update merger 430 merges the data changes with the shared data.

[0031] In examples herein, the logger 410 may log the data changes in the log entries after execution of the application processes and the log fiusher may flush the log entries to the non-volatile storage 130 prior to the update merger 430 merging the data changes with shared data of the multi-threaded application. Accordingly, the log entries may be used to restore a state of the mu!ti-threaded application when a stoppage event occurs in a criticai section of the multi-threaded application.

[0032] In some examples, the example persistence manager 340 of FIGS. 3 and/or 4 may manage a persistent log in the non-volatile storage 130. The example persistent log stores flushed data from log entries (e.g., in a redo log) corresponding to data changes from executed application processes during critical sections of the multi-threaded applications. The persistence manager 340 may periodically (e.g., after designated periods of time, at designated points of time, etc.) or aperiodically (e.g., after compieted execution of a multi-threaded application, after completion of a critical section of an application, etc.) truncate the persistent log to keep the persistent log from getting too large. For example, after each time shared data of the multi-threaded application is written to the non-volatile storage 130, the persistence manager 340 may remove log entries corresponding to data changes from the executed application processes that were merged into the shared data (after they were stored in the log).

Accordingly, the persistence manager 340 may truncate the persistent log to avoid storing multiple instances of the data changes from the executed application processes (i.e., in both the persistent log of the non-volatile storage 130 and the shared application data in the non-volatile storage 130) to ensure the persistent log does not become too large.

[0Θ33] While an example manner of implementing the multi-threaded application manager 1 10 of FIG. 1 is illustrated in FIG. 2 and example implementations of components for the manager for the multi-threaded applications 1 10 are illustrated in FIGS. 3 and/or 4, at least one of the elements, processes and/or devices illustrated in FIG. 2, 3, and/or 4 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the multi-threaded application executor 210 (including the application process generator 310, the critical section controller 320, the application process executor 330, and the persistence manager 340 of FIG. 3 and/or the logger 410, the log fiusher 420, the update merger 430 of FIG. 4) and the restore manager 220 and/or, more generally, the example multi-threaded application manager 1 10 of FIG. 2 may be implemented by hardware and/or any combination of hardware and executable instructions (e.g., software and/or firmware). Thus, for example, any of the application executor 210 (including any of the application process generator 310, the critical section controller 320, the application process executor 330, and the persistence manager 340 of FIG. 3 and/or the logger 410, the log flusher 420, the update merger 430 of FIG. 4) and the restore manager 220 and/or, more generally, the example multi-threaded application manager 1 10 could be implemented by at least one of an analog or digital circuit, a logic circuit, a programmable processor, an application specific integrated circuit (ASIC), a programmable logic device (PLD) and/or a field programmable logic device (FPLD). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the multi-threaded application executor 210 (including at least one of the application process generator 310, the critical section controller 320, the application process executor 330, and the

persistence manager 340 of FIG. 3 and/or the logger 410, the log fiusher 420, the update merger 430 of FIG. 4) and the restore manager 220 is/are hereby expressly defined to include a tangible machine readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the executable Instructions. Further still, the example multi-threaded application manager 1 10 of FIG. 2 may include at least one element, process, and/or device in addition to, or instead of, those illustrated in FIGS. 2, 3, and/or 4 and/or may include more than one of any or ail of the illustrated elements, processes and devices.

[0034] FIG. 5 is a sequence diagram illustrating an example execution of a multi-threaded application 500 by the example multi-threaded application executor 210 of FIG. 2 or 3. in the illustrated example of FIG. 5, two application processes 501 , 502 corresponding to threads THREADi and THREAD2 of a multi-threaded application are executed beginning at time To. Although only two application processes are illustrated in the example of FIG. 5, in some examples, more than two application processes may be executed for a multithreaded application (e.g., in a similar manner). [0035] In the illustrated example of FIG. 5, at time To the application process executor 330 may execute the application processes 501 ,502 in parallel until time Ti . At time Ti the critical section controller 220 may detect a synchronization point (e.g., a beginning of a critical section such as, a lock acquire operation) in the execution of the multi-threaded application 500.

Accordingly, at time Ti the application process executor 330 may select the application process for threadi 501 to continue execution and pause execution of the application process 502. in some examples, the application process executor 330 may use a token to select or determine which of the processes is to be executed first (or second). At time Ti, the application process for threadi 501 continues to execute and starts an operation 510. During a first operation of the critical section 510, the application process executor 330 starts a task execution of the application process for threadi 501 . During task execution, the logger 410 logs data changes in a log entry (or a plurality of log entries) of a log. After the task execution stops, the log flusher 420 flushes the log entry to the non-volatile storage 130. And after flushing the log entry, the update merger 430 merges the data changes from the task execution with shared data in a shared memory space of the memory 120 for the multi-threaded application 500.

[0036] In FIG. 5, at time T₂, the operation 510 ends and the application executor 330 pauses the execution of the application process for threadi and resumes execution of the application process for thread 502. For example, the application executor 330 may pass a token to the application process for fhread2 to enable the application process for thread₂ 502 to resume execution. Similar to the first operation of the critical section 510, the application process executor 330 starts a task execution 520 of the application process for thread^ and the persistence manager 340 (e.g., via the logger 410, the log flusher 420, and the update merger 430) logs data changes in a log entry, flushes the log entry to the non-volatile storage 130 after the task execution ends, and updates the shared data of the multi-threaded application in the shared memory space of the memory 120 for the multi-threaded application 500. At time T3. the second operation 520, and further, the critical section of the multi-threaded application ends, and the application process executor 330 resumes parallel execution of the application processes 501 , 502,

[0037] Accordingly, as shown in FIG, 5, when a critical section of an execution of a multi-threaded application is encountered, the application process executor 330 executes application processes in a sequential manner by selecting a single application process to execute at a time (and pausing the other application processes). As such, after execution of tasks of a first application process (e.g., the application process for threadi 501 ), the data changes are logged and flushed before execution of a subsequent application process (e.g., the application process for thread2 502) resumes. Accordingly, persistent data for the multi-threaded application may be maintained during execution of the multi-threaded application. For example, in the event a stoppage event occurs at time T2, the flushed log entry from the first operation 510 may be used to restore the multi-threaded application to its previous state at time T2.

[0038] FIG. 6 illustrates an example sequence of logging data changes from an executed application process in a critical section (e.g., see FIG. 5) by the persistence manager of FIG. 4. Example representations of shared data 610 of a multi-threaded application, application process data 620, and a redo log 630 for the multi-threaded application are illustrated in FIG, 6. The example shared data, application process data 620 and redo log 630 may be located in the memory 120 (e.g., a cache).

[0039] In FIG. 6, when logging data changes 622 (represented by shaded region), the logger 410 writes the data changes 622 to a log entry and the log fiusher 420 flushes the log to the non-volatile storage 130. As illustrated in FIG. 6, the update merger 430 updates the shared data with the data changes 622 and the writes the shared data back to the non-volatile storage 130 when execution of the application process (or the multi-threaded application) completes.

[0040] Flowcharts representative of example machine readable instructions for implementing the multi-threaded application executor 210 of FIGS. 2 and/or 3 are shown in FIGS, 7 and 8. in this example, the machine readable instructions comprise a process (e.g., a program, an application, etc.) or processes for execution by a processor such as the processor 1012 shown in the example processor platform 1000 discussed below in connection with FIG. 10. The process(es) may be embodied in executable instructions (e.g., software) stored on a tangible machine readable storage medium such as a CD- ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 1012, but the entirety of the

process(es) and/or parts thereof could alternatively be executed by a device other than the processor 1012 and/or embodied in firmware or dedicated hardware. Further, although the example process is described with reference to the flowcharts illustrated in FIGS. 7 and 8, many other methods of implementing the example multi-threaded application executor 210 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

[0041]The example process 700 of FIG. 7 begins with an initiation of the multi-threaded application executor 210 (e.g., upon startup, upon instructions from a user, upon execution of a multi-threaded application (e.g., via a processor, see FIG. 10), upon startup of a component implementing the multithreaded application executor 210 (e.g., the multi-threaded application manager 1 10), etc.). The example process 700 of FIG. 7 may be executed to persist data during an execution of a multi-threaded application. At block 710, the application process generator 310 generates application processes

corresponding to threads of an application (e.g., a multi-threaded application). For example, at block 710, the application process generator 310 may perform a copy-on-write (e.g., via versioning) to create a private copy of each of the multiple threads in separate address spaces of the volatile memory such that the tasks of the threads may be executed as processes in the separate address spaces. At block 720, the critical section controller 320 identifies a critical section of the application. For example, at block 720, the critical section controller 320 may detect a synchronization point (or operation), such as a lock operation. [0042] Αί block 730, the application process executor 330 executes the application processes (e.g., one at a time, in a determined order, etc.) to facilitate reuse of persistent data of the application (e.g., via logging data changes for each application process in a log entry and flushing the log entry). For example, at block 730, for each critical section of a multi-threaded application, the application process executor 330 may iteratively select an application process from the multiple application processes generated from the multiple threads of the multi-threaded application for execution and pause the other threads of the application. Accordingly, at block 730, the example application process executor 330 may identify critical sections of the multithreaded application during execution of the multi-threaded application, and pause/execute application processes In accordance with examples herein (e.g., see FIG. 8). The example blocks 720, 730 may be implemented by executing process 800 of FIG. 8 as discussed below. At block 740, the persistence manager 340 stores shared data of the application in the non-volatile storage 130 (e.g., shared data of the application that is updated as a result of executing application processes corresponding to threads of the application). After block 740, the example process 700 ends. In some examples, after block 740, a restore operation may be implemented to restore the application to a state of the application at the time of a stoppage event (see FIG. 9).

[0043] The example process 800 of FIG. 8 begins with an initiation of the multi-threaded application executor 210. The example process 800 of FIG. 8 may be executed to implement blocks 720, 730 of FIG. 7. At block 801 , the multi-threaded application executor 210 determines whether execution is at the end of the application (i.e., execution of application has completed). If at block 801 , the execution Is at the end of the application, the example process 800 ends. In some examples, after block 801 , control advances to block 740 and the shared data is synchronized (e.g., persisted) in the non-volatile storage 130.

[0044] If at block 801 , the execution is not at the end of the application, at block 810, the multi-threaded application executor 210 (e.g., via the application process executor 330) executes application processes of a multi-threaded application. For example, at block 810, the application process executor 330 executes applications processes in parallel. At block 820, the critical section identifier 320 determines whether a critical section of the multi-threaded application is to be executed (e.g., based on a synchronization operation), if a critical section is not to be executed, control returns to block 801 .

[0045] If a critical section of a multi-threaded application is to be executed (block 820), at block 830, the application process executor 330 allocates a token to a next application process to be executed (e.g., based on type of operation). The token may be used to instruct or indicate which application process from a plurality of application processes corresponding to threads of a multi-threaded application is to be executed. At block 840, the example application process executor 330 executes (or performs) the tasks of the selected application process.

[0046]At block 850 of FIG. 8, the persistence manager 340, via the logger 410, logs data changes resulting from the executed process in a log entry (or a plurality of log entries) of a log. At block 860, the persistence manager 340, via the log flusher 420, flushes the log entry to the non-volatile storage 130. At block 870, the update merger 430 synchronizes process data with the shared data of the application. At block 880, the application process executor 330 determines whether more processes are to be sequentially executed in the critical section, if more processes are to be executed, control returns to block 830 and the token is allocated to the next application process, if, at block 880, there are no more processes to be executed in the critical section, control returns to block 801.

[0047] A flowchart representative of example machine readable instructions for implementing the restore manager 220 of FIG. 2 is shown in FIG. 9. in this example, the machine readable instructions comprise a program/process for execution by a processor such as the processor 1012 shown in the example processor platform 1000 discussed below in connection with FIG. 10. The program/process may be embodied in executable instructions (e.g., software) stored on a tangible machine readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Biu-ray disk, or a memory associated with the processor 1012, but the entire program/process and/or parts thereof could alternatively be executed by a device other than the processor 1012 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in FIG. 9, many other methods of implementing the example restore manager 220 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

[0048] The example process 900 of FIG. 9 begins with an initiation of the restore manager 220 (e.g., upon startup, upon instructions from a user, upon startup of a device implementing the restore manager 220 (e.g., the multithreaded application manager 1 10), etc.). The example process 900 of FIG. 9 may be executed to restore an application state of a multi-threaded application using persistent data stored/generated in accordance with examples herein. At block 910, the restore manager 220 determines that a restore of an application (e.g., a multi-threaded application) has been initiated. For example, the restore manager 220 may detect that an application has been reopened following a stoppage event, such as crash, a power failure, a shutdown, an application restart, etc.

[0049] At block 920 of FIG. 9, the restore manager 220 retrieves log data (e.g., data from log entries of the execution of the application) generated from execution of application processes to restore the state of the application. At block 930, the restore manager 220 updates shared data of the application with the log data. For example, the restore manager 220 may read each log entry, find a corresponding memory page in the shared data, and apply the log entry to the memory page. At block 940, the restore manager 220 instructs the multithreaded application executor 210 to resume execution of the application from the state of the application suing the updated shared data. After block 940, the example process 900 ends, in some examples, after block 900, control may be turned over to the multi-threaded application executor 210 to continue execution of the application (e.g., beginning at block 710 of FIG. 7).

[OOSOJAs mentioned above, the example processes of FIGS. 7, 8, and/or 9 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible machine readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible machine readable storage medium is expressly defined to include any type of machine readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "computer readable storage medium" and "machine readable storage medium" are used interchangeably. Additionally or alternatively, the example processes of FIGS. 7, 9, and/or 9 may be

implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory machine readable medium is expressly defined to include any type of machine readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

[0051]As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" is open ended. As used herein the term "a" or "an" may mean "at least one," and therefore, "a" or "an" do not necessarily limit a particular element to a single element when used to describe the element. As used herein, when the term "or" is used in a series, the term "or" is not, unless otherwise indicated, considered an "exclusive or."

[0052] FIG. 10 is a block diagram of an example processor platform 1000 capable of executing the instructions of FIGS. 7, 8, and/or 9 to implement the multi-threaded application manager 1 10 of FIG. 2 and/or the example components of the multi-threaded application manager 1 10 in FIGS. 3 and 4. The example processor platform 1000 may be or may be included in any type of apparatus, such as a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet, etc.), a personal digital assistant (PDA), an internet appliance, or any other type of computing device.

[0053]The processor platform 1000 of the illustrated example of FIG. 10 includes a processor 1012. The processor 1012 of the illustrated example is hardware. For example, the processor 1012 can be implemented by at least one integrated circuit, logic circuit, microprocessor or controller from any desired family or manufacturer.

[0054] The processor 1012 of the illustrated example includes a local memory 1013 (e.g., a cache). The processor 1012 of the illustrated example is in communication with a main memory including a volatile memory 1014 and a non-volatile memory 1016 via a bus 1018. The volatile memory 1014 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device, in examples herein, the local memory 1013 and/or the volatile memory 1014 may be used to implement the memory 120 of FIG. 1 . The non-volatile memory 1016 may be implemented by flash memory, memristor, phase-change memory, non-volatile random access memory (NVRAM) and/or any other desired type of fast non-volatile memory device (non-volatile memory devices that . In examples herein, the non-volatile memory 1016 may be used to implement the non-volatile storage 130 of FIG. 1. Access to the main memory 1014, 1016 may be controlled by a memory controller (which may be used to implement the multi-threaded application manager 1 10 of FIG. 1 ).

[0055] The processor platform 1000 of the illustrated example also includes an interface circuit 1020. The interface circuit 1020 may be

implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a peripheral component interconnect (PCI) express interface. [0056] In the illustrated example, at least one input device 1022 is connected to the interface circuit 1020. The input device(s) 1022 permit(s) a user to enter data and commands into the processor 1012. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

[0057] At least one output device 1024 is also connected to the interface circuit 1020 of the illustrated example. The output device(s) 1024 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a light emitting diode (LED), a printer and/or speakers). The interface circuit 1020 of the illustrated example, thus, may include a graphics driver card, a graphics driver chip or a graphics driver processor.

[0058] The interface circuit 1020 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1026 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

[0059]The processor platform 1000 of the illustrated example also includes at least one mass storage device 1028 for storing executable instructions (e.g., software) and/or data. Examples of such mass storage device(s) 1028 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

[OeeOJ The coded instructions 1032 of FIGS. 7, 8, and/or 9 may be stored in the mass storage device 1028, in the local memory 1013 in the volatile memory 1014, in the non-volatile memory 1016, and/or on a removable tangible machine readable storage medium such as a CD or DVD.

[0081] From the foregoing, it will be appreciated that the above disclosed methods, apparatus and articles of manufacture enable persistence of data during execution of multi-threaded applications. In examples herein, application processes are generated from threads of multi-threaded applications and the application processes are sequentially executed during critical sections of the multi-threaded applications to enable logging and flushing of data changes during the critical sections. As such, the logged data may enable a restore to a state of the multi-threaded application at the time of a stoppage event even when the stoppage event occurs during critical sections of the multi-threaded application, in examples herein, the log data may facilitate reuse of the persistent data (e.g., via a redo log) that returns the multi-threaded application to its operating state without the use of an undo log.

[0082] Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Claims

CLAIMS What is claimed is:

1. An apparatus:

an application process generator to generate application processes corresponding to threads of an application comprising multiple threads;

a critical section identifier to identify critical sections of the application based on the generated application processes;

an application process executor to execute application processes in the critical sections in a sequential manner to facilitate reuse of persistent data of the application; and

a persistence manager to store shared data from the sequentially executed application processes in a non-volatile storage.

2. The apparatus as defined in claim 1 , wherein the application process generator allocates separate address spaces for the application processes and generates a private copy for each of the application processes in the respective separate address spaces, the generated application processes to be executed in the allocated separate address spaces.

3. The apparatus as defined in claim 1 , wherein the critical section identifier is to identify synchronization points of the application, the synchronization points corresponding to initiating respective synchronization operations of the application.

4. The apparatus as defined in claim 1 , wherein the application process executor is to execute the application processes in a sequential manner by determining an order of executing the application processes in the critical sections of the application.

5. The apparatus as defined in claim 1 , wherein the persistence manager is to facilitate reuse of the persistent data of the application by:

after executing each application process in a critical section:

logging data changes from a private copy of the application process to a log entry of a log;

flushing data from the log entry to a non-volatile memory; and merging the data changes from the private copy of the application process with the shared data of the application.

6. The apparatus as defined in claim 5, wherein the persistence manager is further to truncate a persistent log in the non-volatile memory after the merged shared data of the application is stored in the non-volatile memory by removing log entries corresponding to the data changes of the merged shared data, wherein the persistent log comprises a redo log that stores the flushed data from the log entry in the non-volatile memory until the persistent log is truncated.

7. The apparatus as defined in claim 1 , wherein the persistence manager is to facilitate reuse of the persistent data of the application by restoring a state of the application prior to at least one of a shutdown, a system crash, or a restart of the application.

8. A method comprising:

determining a restore of an application has been initiated;

retrieving log data to restore a state of the application, the log data comprising update data generated from executed application processes of a critical section of the application, the application processes corresponding to respective threads of the application;

updating shared data of the application with the log data; and resuming execution of the application from the state of the application using the updated shared data,

9. The method as defined in claim 8, wherein, the log data is stored in a redo log of a non-volatile memory, and the execution of the application is to use the log data from the redo log without using an undo log of the non-volatile memory by applying a log entry of the redo log to memory pages of the shared data.

10. The method as defined in claim 8, further comprising the execution by: retrieving a data structure for restoring the application;

populating the data structure with the updated shared data; and returning to the application at a starting location of the data structure.

1 1 . A non-transitory machine readable storage medium comprising instructions that, when executed, cause a machine to at least:

in a critical section of a multi-threaded application,

select a first application process corresponding to a first thread of the multi-threaded application for execution;

execute the first application process;

log data changes for the first application process in a log entry of a log in response to executing the first application process;

flush the log entry to a non-volatile memory for persistence of the data changes; and

merge the data changes for the first application process with shared data of the multi-threaded application, the shared data comprising data from application processes corresponding to threads of the multithreaded application.

12. The non-transitory machine readable storage medium of claim 1 1 , wherein the instructions, when executed, further cause the machine to:

create a private copy of the first thread in a separate address space from the shared data, the first application process to be executed in the separate address space.

13. The non-transitory machine readable storage medium of claim 1 1 , wherein the instructions, when executed, further cause the machine to: retrieve the shared data from the non-volatile memory to restore the state of the multi-threaded application.

14. The non-transitory machine readable storage medium of claim 1 1 , wherein the instructions, when executed, further cause the machine to:

store the shared data of the multi-threaded application in the non-volatile memory after merging the data changes into the shared data.

15. The non-transitory machine readable storage medium of claim 1 1 , wherein the instructions, when executed, further cause the machine to:

in the critical section of the muiti-threaded application, after data changes for the first application process are merged with the shared data of the multithreaded application:

select a second application process corresponding to a second thread of the muiti-threaded application for execution,

execute the second application process,

log data changes for the second application process in response to executing the second application process,

flush the logged data changes for the second application to the non-volatile memory, and

merge the data changes for the second application process with the shared data of the muiti-threaded application.