In accordance with an embodiment, described herein is a system and method for loading and transforming data to a cloud database, using a hybrid set-based extract, load, transform approach. During the loading and transforming of large amounts of data, from one or more data sources, a data synchronization application sends small batches of data, in parallel streams, to the database, which operates as a transformation engine to load the data. Each stream can be associated with a separate staging table in the database. For each staging table, the subset of data therein is transformed and loaded, before the next subset is processed. A transform and merge process operating at the database can then be used to transform and merge the data, from each of the staging tables, to the target table.

Operating a data distribution including a data distribution module and a plurality of host-bus adapters coupled to the data distribution module can include defining a coherent group that includes a set of members that includes the plurality of host-bus adapters; providing a group-coherent memory area in each of the set of members; and initiating a one-to-all broadcast message from a one of the plurality of host-bus adapters to all of the set of members when the one of the plurality of host-bus adapters requests a write to its local group-coherent memory area. The group-coherent memory area in each of the set of members is physically mirrored with a temporal coherence and no semaphores or access enables are required to achieve the temporal coherence of the coherent group.

A method for preventing a task-signal deadlock arising due to contention for a mutex in a real-time operating system (RTOS) includes detecting, by a processing unit, a signal notification sent to a task for execution of a signal handler; identifying, by the processing unit, a mutex to be acquired by the signal handler, when the signal notification is detected; determining whether the identified mutex has been acquired by the task; and utilizing, by the processing unit, an alternative stack for execution of the signal handler, in response to determining that the mutex has been acquired by the task, for preventing a task-signal deadlock during the execution.

Generic Concurrency Restriction (GCR) may divide a set of threads waiting to acquire a lock into two sets: an active set currently able to contend for the lock, and a passive set waiting for an opportunity to join the active set and contend for the lock. The number of threads in the active set may be limited to a predefined maximum or even a single thread. Generic Concurrency Restriction may be implemented as a wrapper around an existing lock implementation. Generic Concurrency Restriction may, in some embodiments, be unfair (e.g., to some threads) over the short term, but may improve the overall throughput of the underlying multithreaded application via passivation of a portion of the waiting threads.

A semiconductor device performs a software lock-step. The semiconductor device includes a first circuit group including a first Intellectual Property (IP) to be operated in a first address space, a first bus, and a first memory, a second circuit group including a second IP to be operated in a second address space, a second bus, and a second memory, a third bus connectable to a third memory, and a transfer control circuit coupled to the first to third buses. when the software lock-step is performed, the second circuit group converts an access address from the second IP to the second memory such that an address assigned to the second memory in the second address space is a same as an address assigned to the first memory in the first address space.

A first data accessor acquires a lock associated with a critical section. The first data accessor initiates a help session associated with a first operation of the critical section. In the help session, a second data accessor (which has not acquired the first lock) performs one or more sub-operations of the first operation. The first data accessor releases the lock after at least the first operation has been completed.

Aspects of the disclosure relate to providing and maintaining efficient and effective processing of sets of work items in enterprise computing environments by optimizing distributed and parallelized batch data processing. A computing platform may initialize at least two processing workers. Subsequently, the computing platform may cause a first processing worker to perform a first query on a work queue database and initiate parallel processing of a first set of work items. Thereafter, the computing platform may cause the second processing worker to perform a second query on the work queue database and initiate parallel processing of a second set of work items. In some instances, performing the second query on the work queue database comprises reading at least one work item that was read and locked by the first processing worker.

Generic Concurrency Restriction (GCR) may divide a set of threads waiting to acquire a lock into two sets: an active set currently able to contend for the lock, and a passive set waiting for an opportunity to join the active set and contend for the lock. The number of threads in the active set may be limited to a predefined maximum or even a single thread. Generic Concurrency Restriction may be implemented as a wrapper around an existing lock implementation. Generic Concurrency Restriction may, in some embodiments, be unfair (e.g., to some threads) over the short term, but may improve the overall throughput of the underlying multithreaded application via passivation of a portion of the waiting threads.

The subject technology determines that a first visible version of a key is not one of a N number of newest versions of the key based on searching for the key in a regular space to locate the first visible version of the key. The subject technology performs a search of an undo space to locate a second visible version of the key. The subject technology determines whether the first visible version or the second visible version of the key is newer. The subject technology provides a newer version of the key between the first visible version and the second visible version of the key.

Techniques herein store database blocks (DBBs) in byte-addressable persistent memory (PMEM) and prevent tearing without deadlocking or waiting. In an embodiment, a computer hosts a DBMS. A reader process of the DBMS obtains, without locking and from metadata in PMEM, a first memory address for directly accessing a current version, which is a particular version, of a DBB in PMEM. Concurrently and without locking: a) the reader process reads the particular version of the DBB in PMEM, and b) a writer process of the DBMS replaces, in the metadata in PMEM, the first memory address with a second memory address for directly accessing a new version of the DBB in PMEM. In an embodiment, a computer performs without locking: a) storing, in PMEM, a DBB, b) copying into volatile memory, or reading, an image of the DBB, and c) detecting whether the image of the DBB is torn.