Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 216 2009-10-14
216 Model-Based Design for Embedded Systems
the necessary information needed for each translation step. Based on the
task-dependency information that tells how to connect the tasks, the
translator determines the number of intertask communication channels.
Based on the period and deadline information of tasks, the run-time sys-
tem is synthesized. With the memory map information of each processor,
the translator defines the shared variables in the shared region.
To support a new target architecture in the proposed workflow, we have
to add translation rules of the generic API to the translator, make a target-
specific-OpenMP-translator for data parallel tasks, and apply the generation
rule of task scheduling codes tailored for the target OS. Each step of CIC
translator will be explained in this section.
8.5.1 Generic API Translation
Since the CIC task code uses generic APIs for target-independent specifi-
cation, the translation of generic APIs to target-dependent APIs is needed.
If the target processor has an OS installed, generic APIs are translated into
OS APIs; otherwise, they are translated into communication APIs that are
defined by directly accessing the hardware devices. We implement the OS
API library and communication API library, both optimized for each target
architecture.
For most generic APIs, API translation is achieved by simple redefini-
tion of the API function. Figure 8.6a shows an example where the trans-
lator replaces MQ_RECEIVE API with a “read_port” function for a target
processor with pthread support. The read_port function is defined usingMQ_RECEIVE (port_id, buf, size);
Generic API
1. int read_port(int channel_id, unsigned char *buf, int len) {
2.

(b)
FIGURE 8.6
Examples of generic API translation: (a) MQ_RECEIVE operation, (b) READ
operation.
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 217 2009-10-14
Retargetable, Embedded Software Design Methodology 217
pthread APIs and the memcpy C library function. However some APIs
need additional treatment: For example, the READ API needs different
function prototypes depending on the target architecture as illustrated in
Figure 8.6b. Maeng et al. [14] presented a rule-based translation technique
that is general enough to translate any API if the translation rule is defined
in a pattern-list file.
8.5.2 HW-Interfacing Code Generation
If there is a code segment contained within a HW pragma section and its
translation rule exists in an architecture information file, the CIC translator
replaces the code segment with the HW-interfacing code, considering the
parameters of the HW accelerator and buffer variables that are defined in
the architecture section of the CIC. The translation rule of HW-interfacing
code for a specific HW is separately specified as a HW-interface library code.
Note that some HW accelerators work together with other HW IPs.
For example, a HW accelerator may notify the processor of its completion
through an interrupt; in this case an interrupt controller is needed. The CIC
translator generates a combination of the HW accelerator and interrupt con-
troller, as shown in the next section.
8.5.3 OpenMP Translator
If an OpenMP compiler is available for the target, then task codes with
OpenMP directives can be used easily. Otherwise, we somehow need to
translate the task code with OpenMP directives to a parallel code. Note that
we do not need a general OpenMP translator since we use OpenMP direc-
tives only to specify the data parallel CIC task. But we have to make a sepa-

BCast
share
data
BCast
share
data
Work
in
parallel
region
Work
in
parallel
region
Work
in
parallel
region
Work
in
parallel
region
Receive
&
update
Send
shared
data
Send
shared

POSIX-compliant, we generate a thread-based scheduling code, as shown in
Figure 8.8a. A POSIX thread is created for each task (lines 17 and 18) with
an assigned priority level if available. The thread, as shown in lines 3 to 5,
executes the main body of the task, “{task name}_go(),” and schedules the
thread itself based on its timing constraints by calling the “sleep()” method.
If the OS is not POSIX-compliant, the CIC translator should be extended to
generate the OS-specific scheduling code.
If there is no available OS for the target processor, the translator should
synthesize the run-time scheduler that schedules the mapped tasks. The CIC
translator generates a data structure of each task, containing three main
functions of tasks (“init(), go(), and wrapup()”). With this data structure, a
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 219 2009-10-14
Retargetable, Embedded Software Design Methodology 219
1. void
∗
thread_task_0_func(void
∗
argv) {
2.
3. task_0_go();
4. get_time(&time);
5. sleep(task_0->next_period – time); // sleep for remained time
6.
7. }
8. int main() {
9.
10. pthread_t thread_task_0;
11. sched_param thread_task_0_param;
12.
13. thread_task_0_param.sched_priority = 0;

8. , {task2_init, task2_go, task2_wrapup, 200, 0}};
9.
10. void scheduler() {
11. while(all_task_done()==FALSE) {
12. int taskld = get_next_task();
13. taskInfo[taskld]->go()
14. }
15. }
16.
17. int main() {
18. init(); /
∗
{task_name}_init() functions are called
∗
/
19. scheduler(); /
∗
scheduler code
∗
/
20. wrapup(); /
∗
{task_name}_wrapup() functions are called
∗
/
21.return0;
22.}
(b)
FIGURE 8.8
Pseudocode of generated scheduling code: (a) if OS is available, and (b) if OS

Local mem. HW1 HW2
Arm926ej-s
Interrupt ctrl.
Local mem. HW1 HW2
Arm926ej-s
HW3
Shared memory
FIGURE 8.9
The target architecture for preliminary experiments. (From Kwon, S. et
al., ACM Trans. Des. Autom. Electron. Syst., 13, Article 39, July 2008. With
permission.)
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 221 2009-10-14
Retargetable, Embedded Software Design Methodology 221
TABLE 8.1
Task Mapping to Processors
The Configuration of Task Mapping
Processor Id 1 2 3
0 Task 0, Task 1, Task 2,
Task 3, Task 4, Task 5
Task 0, Task 2, Task 3,
Task 4, Task 5
Task 0, Task 3,
Task 4, Task 5
1 N/A Task 1 Task 1
2N/A N/A Task2
Source: Kwon,S.etal.,ACM Trans. Des. Autom. Electron. Syst., 13, Article 39, July 2008. With
permission.
TABLE 8.2
Execution Cycles for Nine Configurations
The Configuration of Task Mapping

/
∗
code segments for IDCT
∗
/
}
(a)
1. <hardware>
2. <name>IDCT</name>
3. <protocol>IDCT_slave</protocol>
4. <param>0x2F000000</param>
5. </hardware>
(b)
1. <hardware>
2. <name>IDCT</name>
3. <protocol>IDCT_interrupt</protocol>
4. <param>0x2F000000</param>
5. </hardware>
6. <hardware>
7. <name>IRQ_CONTROLLER</name>
8. <protocol>irq_controller</name>
9. <param>0xA801000</param>
10. </hardware>
(c)
FIGURE 8.10
(a) Code segment wrapped with HW pragma and architecture section infor-
mation of IDCT, (b) when interrupt is not used, and (c) when interrupt is
used. (From Kwon, S. et al., ACM Trans. Des. Autom. Electron. Syst., 13, Article
39, July 2008. With permission.)
HW accelerator. Two kinds of inverse discrete cosine transformation (IDCT)

idct_base = (volatile unsigned int
∗
) 0x2F000000;
3. while(idct_base[0]==1); // try to obtain hardware resource
4. for (i=0;i<32;i++) idct_base[i+16]= ((unsigned int
∗
)(input.data))[i];
5. idct_base[1]= 1; // send start signal to IDCT accelerator
6. while(idct_base[2]==0); // wait for completion of IDCT operation
7. for (i=0;i<32;i++) ((unsigned int
∗
)(output.data)[i] = idct_base[i+48];
8. idct_base[3]= 1; // clear and unlock hardware
(b)
FIGURE 8.11
(a) The address map of IDCT, and (b) its generated interfacing code. (From
Kwon,S.etal.,ACM Trans. Des. Autom. Electron. Syst., 13, Article 39, July
2008. With permission.)
the complete flag. The address of the complete flag (address 8 in Figure 8.11a)
is assigned to “interrupt clear.”
Figure 8.12a shows the generated interfacing code for the IDCT with
interrupt. Note that the interfacing code does not access the HW to check
the completion of IDCT, but checks the variable “complete.” In the gener-
ated code of the interrupt handler, this variable is set to 1 (Figure 8.12b). The
initialize code for the interrupt controller (“initDevices()”) is also generated
and called in the “{task_name}_init()” function.
8.6.3 Scheduling Code Generation
We generated the task-scheduling code of the H.263 decoder while chang-
ing the working conditions, OS support, and scheduling policy. At first, we
used the eCos real-time OS for arm926ej-s in the RealView SoC designer,

(a)
1. extern int complete;
2. __irq void IRQ_Handler() {
3. IRQ_CLEAR(); // interrupt clear of interrupt controller
4. idct_base[2] =1; // interrupt clear of IDCT
5. complete=1;
6. }
7. void initDevices(){
8. IRQ_INIT(); // initialize of interrupt controller
9. }
(b)
FIGURE 8.12
(a) Interfacing code for the IDCT with interrupt, and (b) the interrupt handler
code. (From Kwon, S. et al., ACM Trans. Des. Autom. Electron. Syst., 13, Article
39, July 2008. With permission.)
For a processor without OS support, the current CIC translator supports
two kinds of scheduling code: default and rate-monotonic scheduling (RMS).
The default scheduler just keeps the execution frequency of tasks considering
the period ratio of tasks. Figure 8.14a and b show the pseudocode of function
get_next_task(), which is called in the function scheduler() of Figure 8.8b, for
the default and RMS, respectively.
8.6.4 Productivity Analysis
For the productivity analysis, we recorded the elapsed time to manually
modify the software (including debugging time) when we change the target
architecture and task mapping. Such manual modification was performed by
an expert programmer who is a PhD student.
For a fair comparison of automatic code generation and manual-coding
overhead, we made the following assumptions. First, the application task
codes are prepared and functionally verified. We chose an H.263 decoder as
the application code that consists of six tasks, as illustrated in Figure 8.3.

S. et al., ACM Trans. Des. Autom. Electron. Syst., 13, Article 39, July 2008. With
permission.)
1. int get_next_task() {
2. a. find executable tasks
3. b. find the tasks that has the smallest value of time count
4. c. select the task that is not executed for the longest time
5. d. add period to the time count of selected task
6. e. return selected task id
7. }
(a)
1. int get_next_task() {
2. a. find executable tasks
3. b. select the task that has the smallest period
4. c. update task information
5. d. return selected task id
6. }
(b)
FIGURE 8.14
Pseudocode of “get_next_task()” without OS support: (a) default, and (b)
RMS scheduler. (From Kwon, S. et al., ACM Trans. Des. Autom. Electron. Syst.,
13, Article 39, July 2008. With permission.)
for the IDCT function block. Third, the software environment for the tar-
get system is prepared, which includes the run-time scheduler and target-
dependent API library.
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 226 2009-10-14
226 Model-Based Design for Embedded Systems
Arm926ej-s
Local mem.
Arm926ej-s
Local mem.

overhead increases as total code size increases, since we need to identify the
target-dependent codes throughout the entire application code.
Next, we changed the target architecture to those shown in Figure 8.15b
and c by using two kinds of IDCT HW IPs. The interface code between pro-
cessor and IDCT HW should be inserted. It took about 2–3 h to write and
debug the interfacing code with IDCT HW IP, without and with the inter-
rupt controller, respectively. The sizes of the interface without and with the
interrupt controller were 14 and 48 lines of code, respectively. Note that the
overhead will increase if the HW IP has a more complex interfacing protocol.
Last, we modified the task mapping by adding one more processor, as
shown in Figure 8.15d. For this analysis, we needed to make an additional
data structure of software tasks to link with the run-time scheduler on each
processor. It took about 2 h to make the data structure of all tasks and attach
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 227 2009-10-14
Retargetable, Embedded Software Design Methodology 227
TABLE 8.3
Time Overhead for Manual Software Modification
Description Code Line Time (h)
Figure 8.15a →
Figure 8.15b and c
Initial porting overhead to the
target simulator
167 of 2400 5
MakingHWinterfacecodeofIDCT
(Figure 8.15a → Figure 8.15b)
14 2
Modifying HW interface code to use
interrupt controller (Figure 8.15a
→ Figure 8.15c)
48 3

thermore, the functional parallelism and data parallelism of application tasks
are specified independently of the target architecture and design constraints.
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 228 2009-10-14
228 Model-Based Design for Embedded Systems
Then, the CIC translator translates the CIC into the final parallel code, con-
sidering the target architecture and design constraints, to make the CIC
retargetable. Temporal parallelism is exploited by inserting pipeline buffers
between CIC tasks and where to put the pipeline buffers is determined at
the mapping stage. We have developed a mapping algorithm that considers
temporal parallelism as well as functional and data parallelism [17].
Preliminary experiments with a H.263 decoder example prove the viabil-
ity of the proposed parallel programming framework: It increases the design
productivity of MPSoC software significantly. There are many issues to be
researched further in the future, which include the optimal mapping of CIC
tasks to a given target architecture, exploration of optimal target architec-
ture, and optimizing the CIC translator for specific target architectures. In
addition, we have to extend the CIC to improve the expression capability of
the model.
References
1. Message Passing Interface Forum, MPI: A message-passing interface
standard, International Journal of Supercomputer Applications and High Per-
formance Computing, 8(3/4), 1994, 159–416.
2. OpenMP Architecture Review Board, OpenMP C and C++ application
program interface, http://www.openmp.org, Version 1.0, 1998.
3. M. Sato, S. Satoh, K. Kusano, and Y. Tanaka, Design of OpenMP compiler
for an SMP cluster, in EWOMP’99, Lund, Sweden, 1999.
4. F. Liu and V. Chaudhary, A practical OpenMP compiler for system on
chips, in WOMPAT 2003, Toronto, Canada, June 26–27, 2003, pp. 54–68.
5. Y. Hotta, M. Sato, Y. Nakajima, and Y. Ojima, OpenMP implementation
and performance on embedded renesas M32R chip multiprocessor, in

14. J. Maeng, J. Kim, and M. Ryu, An RTOS API translator for model-driven
embedded software development, in 12th IEEE International Conference on
Embedded and Real-Time Computing Systems and Applications (RTCSA’06),
Sydney, Australia, August 16–18, 2006, pp. 363–367.
15. S. Ha, C. Lee, Y. Yi, S. Kwon, and Y. Joo, PeaCE: A hardware-software
codesign environment for multimedia embedded systems, ACM Transac-
tions on Design Automation of Electronic Systems (TODAES), 12(3), Article
24, August 2007.
16. Carbon
R

SoC Designer homepage, http://carbondesignsystems.com/
products_socd.shtml
17. H. Yang and S. Ha, Pipelined data parallel task mapping/scheduling
technique for MPSoC, in DATE 2009, Nice, France, April 2009.
18. S. Kwon, Y. Kim, W. Jeun, S. Ha, and Y Paek, A retargetable parallel-
programming framework for MPSoC, ACM Transactions on Design
Automation of Electronic Systems (TODAES), 13(3), Article 39, July 2008.
Nicolescu/Model-Based Design for Embedded Systems 67842_C008 Finals Page 230 2009-10-14
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 231 2009-10-13
9
Programming Models for MPSoC
Katalin Popovici and Ahmed Jerraya
CONTENTS
9.1 Introduction 231
9.2 Hardware–SoftwareArchitectureforMPSoC 234
9.2.1 Hardware Architecture 235
9.2.2 Software Architecture 235
9.2.3 Hardware–Software Interface . 236
9.3 ProgrammingModels 237

to be a multitile architecture that integrates hundreds of DSP and microcon-
trollers on a single chip [6]. The software running on these heterogeneous
MPSoC architectures is generally organized into several stacks made of dif-
ferent software layers.
Programming heterogeneous MPSoC architectures becomes a key issue
because of two competing requirements: (1) Reducing the software devel-
opment cost and the overall design time requires a higher level program-
ming model. Usually, high level programming models diminish the amount
of architecture details that need to be handled by the application software
designers, and accelerates the design process. The use of high level program-
ming model also allows concurrent software–hardware design, thus reduc-
ing the overall SoC design time. (2) Improving the performance of the overall
system requires finding the best matches between the hardware and the soft-
ware. This is generally obtained through low level programming. Thus, the
key challenge is to find a programming environment able to satisfy these two
opposing requirements.
Programming MPSoCs means generating software stacks running on the
various processors efficiently, while exploiting the available resources of the
architecture. Producing efficient code requires that the software takes into
account the capabilities of the target platform. For instance, a data exchange
between two different processors may use different schemes (global mem-
ory accessible by both processing units, local memory of the one of the pro-
cessors, dedicated hardware FIFO components, etc.). Additionally, different
synchronization schemes (polling, interrupts) may be used to coordinate this
data exchange. Each of these communication schemes has advantages and
disadvantages in terms of performance (e.g., latency, throughput), resource
sharing (e.g., multitasking, parallel I/O), and communication overhead (e.g.,
memory size, execution time).
In an ideal design flow, programming a specific architecture consists
of partitioning and mapping, application software code generation, and

HW
abstraction
Hardware
platform
Executable
model
generation
Executable model
Debug and
performance
validation
FIGURE 9.2
Software development platform.
as a high level representation produces an executable model that emulates
the execution of the final system including hardware and software architec-
ture. Generic software development platforms have been designed to fully
abstract the hardware–software interfaces, for example, MPITCH is a run
time execution environment designed to execute parallel software code writ-
ten using MPI [7]. The use of generic platforms does not allow simulating
the software execution with detailed hardware–software interaction. There-
fore, it does not allow debugging the lower layers of the software stack,
for instance, the OS or the implementation of the high level communication
primitives. The validation and debug of the HdS is the main bottleneck in
MPSoC design [8] because each processor subsystem requires specific HdS
implementation to be efficient.
The use of programming models for the software design of heteroge-
neous MPSoC requires the definition of new design automation methods to
enable concurrent design of hardware and software. This also requires new
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 234 2009-10-13
234 Model-Based Design for Embedded Systems

between the different CPUs is performed through a global shared memory.
The message passing organization assumes multiple software stacks running
on nonidentical subsystems that may include different CPUs and/or a differ-
ent I/O systems in addition to specific local memory architectures. The com-
munication between the different subsystems generally proceeds by message
passing. Heterogeneous MPSoCs generally combine both models to integrate
a massive number of processors on a single chip [10]. Future heterogeneous
MPSoC will be made of few heterogeneous subsystems, where each subsys-
tem may include a massive number of the same processor to run a specific
software stack.
In the following sections, we describe the hardware organization, soft-
ware stack composition, and the hardware–software interface for MPSoC
architectures.
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 235 2009-10-13
Programming Models for MPSoC 235
Task qTask 2Task 1
Task pTask 2Task 1
SW-SS HW-SS
Intra-subsyst comm.
Task nTask 2Task 1
Intra-subsyst comm.
CPU
HAL
HAL API
HDS API
Comm OS
Peripherals
Inter-subsystem communication
SoftwareHardware
HdS Application

236 Model-Based Design for Embedded Systems
The second layer consists in the OS and communication middleware
(Comm) layer. This software layer is responsible for providing the necessary
services to manage and share resources. The software includes scheduling
of the application tasks on top of the available processing elements, inter-
task communication, external communication, and all other types of resource
management and control services. Conventionally, these services are pro-
vided by the OS and additional libraries for the communication middleware.
At this level, the hardware dependency is kept functional, i.e., it concerns
only high level aspects of the hardware architecture such as the type of avail-
able resources. The OS and communication layer make use of HAL APIs to
abstract the underlying HAL layer.
Low level details about how to access these resources are abstracted by
the third layer, which is the HAL. The separation between OS and HAL
makes thereby the architecture exploration for the design of both the CPU
subsystem and the OS services easier, enabling easy software portability. The
HAL is a thin software layer that not only completely depends on the type
of processor that will execute the software stack, but also depends on the
hardware resources interacting with the processor. The HAL also includes
the device drivers to implement the interface for the communication with
the various devices.
9.2.3 Hardware–Software Interface
The hardware–software interface links the software part with the hardware
part of the system. As illustrated in Figure 9.4, the hardware–software inter-
face needs to handle two different interfaces: one on the software side using
APIs and one on the hardware side using wires [11]. This heterogeneity
makes the hardware–software interface design very difficult and time con-
suming because the design requires both, hardware and software knowledge
Specific
HWIP

The hardware–software interface has different views depending on the
designer. Thus, for an application software designer, the hardware–software
interface represents a set of system call used to hide the underlying exe-
cution platform, also called programming model. For a hardware designer,
the hardware–software interface represents a set of registers, control signals,
and more sophisticated adaptors to link the processor to the HW-SS. For a
system software designer, the hardware–software interface is defined as the
low level software implementation of the programming model for a given
hardware architecture. In this case, the processor is the ultimate hardware–
software interface. This is a sequential scheme assuming that the hardware
architecture is the starting point for the low level software design. Finally,
for a SoC designer the hardware–software interface abstracts both hardware
and software in addition to the processor.
9.3 Programming Models
Several tools exist for the automatic mapping of sequential programs on
homogeneous multiprocessor architectures. Unfortunately, these are not effi-
cient for heterogeneous MPSoC architectures. In order to allow the design
of distributed applications, programming models have been introduced and
extensively studied by the software communities to allow high level pro-
gramming of heterogeneous multiprocessor architectures.
9.3.1 Programming Models Used in Software
As long as only the software is concerned, Skillicorn and Talia [13] iden-
tifies five key concepts that may be hidden by the programming model,
namely concurrency or parallelism of the software, decomposition of the
software into parallel threads, mapping of threads to processors, communi-
cation among threads, and synchronization among threads. These concepts
define six different abstraction levels for the programming models. Table 9.1
summarizes the different levels with typical corresponding programming
languages for each of them. All these programming models take into account
only the software side. They assume the existence of lower levels of software

TLM SystemC [16] Resources sharing
and control
strategies
Virtual prototype Cosimulation with ISS ISA and detailed
I/O interrupts
hardware components. Similar to the programming models for software,
the hardware–software interfaces may be described at different abstraction
levels. The four key concepts that we consider are the following: explicit
hardware resources, management and control strategies for the hardware
resources, the CPU architecture, and the CPU implementation. These con-
cepts define four abstraction levels, named system architecture level, virtual
architecture level, transaction accurate architecture level, and virtual proto-
type level [14]. The four levels are presented in Table 9.2.
At the system architecture level, all the hardware is implicit similar to
the message passing model used for software. The hardware–software par-
titioning and the resources allocation are made explicit. This level fixes also
the allocation of the tasks to the various subsystems. Thus, the model com-
bines both the specification of the application and the architecture and it
is also called combined architecture algorithm model (CAAM). At the vir-
tual architecture level, the communication resources, such as global inter-
connection components and buffer storage components, become explicit. The
transaction accurate architecture level implements the resources manage-
ment and control strategies. This level fixes the OS on the software side. On
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 239 2009-10-13
Programming Models for MPSoC 239
the hardware side, a functional model of the bus is defined. The software
interface is specified at the HAL level, while the hardware communication is
defined at the bus transaction level. Finally, the virtual prototype level cor-
responds to the classical cosimulation with instruction set simulators (ISSs)
[17]. At this level the architecture of the CPU is fixed, but not yet its imple-

The task transaction level interface (TTL) proposed in [18] focuses on
stream processing applications in which concurrency and communication
Nicolescu/Model-Based Design for Embedded Systems 67842_C009 Finals Page 240 2009-10-13
240 Model-Based Design for Embedded Systems
TABLE 9.3
Programming Model API at Different Abstraction Levels
Hardware
Abstraction Communication Task and Access
Level Primitives Resources Control Primitives
System
architecture
Implicit, e.g.,
Simulink links
Implicit, e.g., Simulink
blocks
Implicit, e.g.,
Simulink links
Virtual
architecture
Data exchange, e.g.,
send–receive(data)
Implicit tasks control,
e.g., threads in
SystemC
Specific I/O
protocols
related to
architecture
Transaction
accurate

scalars, which requires the definition of explicit addressing schemes. This
corresponds to the transaction accurate architecture level APIs.
The Multiflex approach proposed in [10] targets multimedia and net-
working applications, with the objective of having good performance even
for small granularity tasks. Multiflex supports both a symmetric multipro-
cessing (SMP) approach that is used on shared memory multiprocessors, and
a remote procedure call–based programming approach called DSOC (dis-
tributed system object component). The SMP functionality is close to the
one provided by POSIX, that is, it includes thread creation, mutexes, con-
dition variables, etc. [19] The DSOC uses a broker to spawn the remote
methods. These abstractions make no separation between virtual architec-
ture and transaction accurate architecture levels, since they rely on fixed
synchronization mechanisms. Hardware support for locks and run queues