Specifications

Red Hat Enterprise Linux to Oracle Solaris Porting Guide
54
Signals in Threaded Applications
The RHEL POSIX thread implementation is process-centric. On RHEL, as far as signals are
concerned, each thread is viewed as an independent process (LWP). The RHEL kernel does not really
differentiate between threads and processes. As a matter of fact, within a single process, the threads
share many resources such as virtual memory, file descriptors, global variables, and so on. Because of
this basic difference, the signals might not get handled correctly (in a POSIX–compliant way) in RHEL
by multithreaded applications. In RHEL, the signals are directly sent to individual threads and not to
the process as a whole (this is a deviation from the POSIX standard). The POSIX standard mandates
that the signal received by a process can be handled by any single thread within the targeted process.
Programs that depend on this aspect of signal delivery might find issues with this difference in
implementation. It is important to note that this issue has already been addressed in the latest RHEL
kernel patches, so whether a multithreaded application would face this issue is entirely dependent on
the application's base development platform.
Getting the Most out of Oracle Solaris 11
Support for Latest Hardware Technologies
Historically, throughput has been a measure of the comparative effectiveness of large commercial
computers that run many programs concurrently. When Oracle’s family of SPARC processors based
on chip multithreading (CMT) technology was first introduced, the concept of throughput computing
was presented as a means to cut the cost and complexity of network computing. The idea is to use
CMT-enabled processors to maximize application workload throughput. This means maximizing the
aggregate amount of work done in a given amount of time on both a per-processor and a per-system
basis.
By combining multicore processors with CMT technology, we can increase the overall throughput of
the processor (socket) by the number of cores on the processor. This approach enables increased
performance at a lower cost because fewer systems are required, which also means reduced power
consumption, lower maintenance and administration costs, and increased reliability due to fewer
systems.
In a CMT processor, a single core typically contains eight or more hardware threads. The CMT
processors execute multiple software threads simultaneously on these hardware threads and this, in
turn, can help improve price/performance and reduce the total cost of ownership. Unlike traditional
single-threaded processors and even most current multicore processors, hardware multithreaded
processors, such as Oracle’s SPARC T4 processors, allow rapid switching between active threads as
other threads stall for memory. On a CMT processor, each core is designed to switch between multiple
threads on each clock cycle. As a result, the processor’s execution pipeline remains active doing useful
work, even as memory operations for stalled threads continue in parallel.
Thread-rich applications, which are common in commercial workloads, benefit greatly from this model
whether they comprise large multithreaded applications or large numbers of smaller single-threaded