Colorama: Ar chitectural Support for Data-Centric Synchr onization · 2007. 9. 14. · Luis Ceze Colorama February 2007 NYV\W Colorama: Ar chitectur e Support for DCS ¥ Main advantage:

$Page 1: Colorama: Ar chitectural Support for Data-Centric Synchr onization · 2007. 9. 14. · Luis Ceze Colorama February 2007 NYV\W Colorama: Ar chitectur e Support for DCS ¥ Main advantage:$
Colorama: Architectural Support for

Data-Centric Synchronization

Luis Ceze, Pablo Montesinos,

Christoph von Praun! and Josep Torrellas

HPCA, February 2007

http://iacoma.cs.uiuc.edu

University of Illinois at Urbana-Champaign!IBM Research

Luis Ceze Colorama February 2007

Challenge: Simplify Parallel Programming

2



•Thread synchronization is very challenging

2




•Lock-based synchronization:

• coarse-grain: low performance; fine-grain: error-prone

2






•Transactional Memory-based synchronization:

• programmability ~ coarse-grain locking; performance ~ fine-grain locking

2








•Locks and TM shortcoming:

• programmer needs to annotate code around every potential access to

shared data

2










shared data

2

Need to make parallel programming much simpler:










shared data

2

Need to make parallel programming much simpler:

"Data-Centric Synchronization (DCS)


Conventional: Code-Centric

Synchronization (CCS)

3

Colorama: Data-Centric

Synchronization (DCS)




3

declare A,B,C






3

A B Cdeclare A,B,C






3

A B Cdeclare A,B,C






3

lock L1ld A

st A

st B

unlock L1

A B Cdeclare A,B,C






3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

A B Cdeclare A,B,C






3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

A B Cdeclare A,B,C






3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

A B Cdeclare A,B,C declare A,B,C



A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2




A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2


color red A,B



A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2


color red A,B



color blue C

A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2


color red A,B



color blue C

A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

ld A

st A

st B


color red A,B



color blue C

A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

ld A

st A

st B

ld C

st C


color red A,B



color blue C

A B C




3

lock L1ld A

st A

st B

unlock L1

lock L2ld C

st C

unlock L2

ld A

st A

st B

ld C

st C

System infers and

enforces critical sections


color red A,B



color blue C


DCS Reduces Programmer Effort

4



4

code-centric data-centric



4


reasoning non-local local



4



critical

sectionsexplicitly

defined

inferred by

system



4



critical

sectionsexplicitly

defined

inferred by

system

"Intuition: Local reasoning improves programmer

productivity by reducing chances of mistakes


Example from mysql

5


Example from mysql

5

header

info

• all header protected by global lock

• global lock used in 29 sites


Example from mysql

5

header

info



•info protected by per-record lock

• per-record lock used in 14 sites


Example from mysql

5

header

info

CCS






Example from mysql

5

header

info

CCS





•header fields same color

• each info different color

DCS


Example from mysql

5

header

info


Software DCS

6


Software DCS

•Software-only DCS concurrently developed [Vaziri PoPL’06]

• for object-oriented languages (Java)

6


Software DCS



•Needs whole-program analysis

6


Software DCS



•Needs whole-program analysis

•Impractical in C/C++

• Pointer aliasing

• Compiler often does not have access to whole code

6


Colorama: Architecture Support for DCS

7



•Main advantage: HW can cheaply watch all memory refs

7




•Enter critical section when colored data is touched

7





• HW checks the color of every memory access

7






• Interface to assign colors to shared data (memory tagging)

7







•Exit critical section using an Exit Policy

7








• HW provides flexible primitives to exit critical sections

7









• Compiler inserts the code that implements the policy

7










• Programmer must know (and follow) the Exit Policy

7










• Programmer must know (and follow) the Exit Policy

•Structures to keep track of color ownership

7


Architecture Components

8

Start

Address

End

Address ColorID

Palette

Shared



8

Start

Address

End

Address ColorID

Palette

Shared Per Thread

Owned Colors Array

Color Acquire Bitmap

Register (CAB)

Color Release Bitmap

Register (CRB)

Thread Color Status

ColorIDi



8


Colorama Operation Example

9

Palette

Owned Colors

Array



9

color A red

color B red

color C red

color E blue

color F blue

Palette

Owned Colors

Array



9

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue

Owned Colors

Array



9

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue

Owned Colors

Array

thread 1



9

ld A

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue

Owned Colors

Array

thread 1



9

ld A

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue

!trap to user-level handler, start red critical section

Owned Colors

Array

thread 1



9

ld A

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue


Owned Colors

Array

red

thread 1



9

ld A

st B

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue


Owned Colors

Array

red

thread 1



9

ld A

st B

st C

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue


Owned Colors

Array

red

thread 1



9

ld A

st B

st C

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue


!trap to user-level handler, exit red critical section

Owned Colors

Array

red

thread 1



9

ld A

st B

st C

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array

thread 1



9

ld A

st B

st C

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array

thread 1



9

ld A

st B

st C

st E

st F

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array

blue

!trap to user-level handler, start blue critical section

thread 1



9

ld A

st B

st C

st E

st F

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array

blue


!trap to user-level handler, exit blue critical section

thread 1



9

ld A

st B

st C

st E

st F

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array



thread 1



9

ld A

st B

st C

st E

st F

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array



thread 1

inferred critical

sections



9

ld A

st B

st C

st E

st F

color A red

color B red

color C red

color E blue

color F blue

Palette

A red

B red

C red

E blue

F blue



Owned Colors

Array



thread 1

inferred critical

sections

Underlying synchronization substrate:

TM or locks. Focusing on TM.


Exiting a Critical Section

10



•Knowing when to end a critical section is difficult

10




•Optimal place undecidable

10





•Solution is to rely on an agreed Exit Policy

• Exit Policy becomes part of the programming model

10





•Solution is to rely on an agreed Exit Policy

• Exit Policy becomes part of the programming model

•We use:

• Return of subroutine where the critical section started [Vaziri’06, Wang’06]

10


Exit Policy

11


Exit Policy

11

void foo1()

{

...

...

A = ...

...

...

...

}

ColorIDA

critical

section


Exit Policy

11

void foo1()

{

...

...

A = ...

...

...

...

}

ColorIDA

critical

section

void foo1()

{

...

...

A = ...

...

...

B = ...

...

...

}

ColorIDA

critical

sectionColorID

B

critical

section


Exit Policy

11

void foo1()

{

...

...

A = ...

...

...

...

}

ColorIDA

critical

section

void foo1()

{

...

A = ...

foo2();

...

}

void foo2()

{

...

B = ...

...

}

ColorIDA

critical

section

ColorIDB

critical

section

void foo1()

{

...

...

A = ...

...

...

B = ...

...

...

}

ColorIDA

critical

sectionColorID

B

critical

section

Start

Address

End

Address ColorID

Palette

Shared Per Thread

Owned Colors Array


Register (CAB)

Color Release Bitmap

Register (CRB)

Thread Color Status

ColorIDi



12


Detailed Operation

13

f()Color Acquire Bitmap

(CAB register)Owned Colors

Array


Detailed Operation

13


(CAB register)

ld Z

Owned Colors

Array


Detailed Operation

13


(CAB register)

1ld Z

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()


(CAB register)

1ld Z

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()


(CAB register)

1ld Z

stack " CAB

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()


(CAB register)

1ld Z

stack " CAB

CAB " 0

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()


(CAB register)

ld Z

stack " CAB

CAB " 0

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()


(CAB register)

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()

ld A


(CAB register)

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

Blue


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

Blue

Red


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

ld T

Blue

Red


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

ld B

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

ld T

Blue

Red


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0...

Owned Colors

Array

ld T

Blue

Red

Green


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0

...

...

Owned Colors

Array

ld T

Blue

Red

Green


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

...

...

Owned Colors

Array

ld T

Blue

Red

Green


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB ! exits critical sections Red and Green

...

...

Owned Colors

Array

ld T

Blue

Red

Green


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB ! exits critical sections Red and Green

...

...

Owned Colors

Array

ld T

Blue


Detailed Operation

13

f()

call g()

ld A

1


(CAB register)

1

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

CAB " stack

! exits critical sections Red and Green

...

...

Owned Colors

Array

ld T

Blue


Detailed Operation

13

f()

call g()

ld A


(CAB register)

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

CAB " stack


1

...

...

Owned Colors

Array

ld T

Blue


Detailed Operation

13

f()

call g()

ld A


(CAB register)

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

CAB " stack


...

ret

1

...

...

Owned Colors

Array

ld T

Blue


Detailed Operation

13

f()

call g()

ld A


(CAB register)

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

CAB " stack


...

ret

1

...

...

subroutine prologue/epilogue

inserted by the compiler

Owned Colors

Array

ld T

Blue


Detailed Operation

13

f()

call g()

ld A


(CAB register)

ld B

ld Z

stack " CAB

CAB " 0

CRB " CAB

CAB " stack


...

ret

1

...

...

subroutine prologue/epilogue

inserted by the compiler

Owned Colors

Array

ld T

Blue

Hardware is generic: exit policy

configurable and specified by SW.

Protection

Lookaside

Buffer (PLB)

Processor

Multilevel

Permissions

Table

Memory

MMP with the Palette extensions


Palette Implementation

14

Mondrian Memory Protection [Witchel ASPLOS’02]


Why Multiple Colors?

15



•Intuitive way of nesting inferred transactions

15




•Conveys more information on how shared data is used

15





• Allows future exit policy refinement

15






• More opportunity for optimizations

15







• e.g., assume transactions of different colors do not collide

15







• e.g., assume transactions of different colors do not collide

•Lock-based implementation: each color maps to a lock

15


Using Colorama to Debug Conventional Code

16



•Programmer uses explicit transactions AND colors data

16




•The system can monitor:

16





" colored data should only be accessed inside transactions

16






" transactions of different colors should not collide

16






" transactions of different colors should not collide

" transactions should typically access a single color

- if multiple colors are accessed, nesting could be recommended

16


Evaluation

17


Evaluation

•No large Colorama programs (yet)

17


Evaluation


•Evaluation consists in detailed profiling of open-source

parallel programs

• Developed Pin tool to profile critical sections and memory allocation

• Used MySQL, FireFox, aolserver, tuxracer, ...

17


Evaluation



parallel programs



•Estimated Exit Policy suitability

• Majority of critical sections entry/exit are inside same subroutine

17


Evaluation



parallel programs



•Estimated Exit Policy suitability

• Majority of critical sections entry/exit are inside same subroutine

•Estimated overheads

• Palette increases memory footprint by about 2.5%

17


Also in the paper...

•More examples

•Detailed API

•Lock-based implementation issues

•Code compatibility issues

• conditional wait, linking with non-Colorama code, ...

•Debugging Colorama code

•Additional characterization

18


Conclusion

19


Conclusion

•We presented a feasible implementation of DCS

19


Conclusion


•DCS can greatly simplify parallel programming

• programmer only specifies the colors and follows a simple policy

• the system, in return, guarantees consistency of shared data

19


Conclusion


•DCS can greatly simplify parallel programming

• programmer only specifies the colors and follows a simple policy

• the system, in return, guarantees consistency of shared data

•Current work:

• Other exit policies under investigation

• Deeper evaluation

19

Colorama: Architectural Support for

Data-Centric Synchronization

Luis Ceze, Pablo Montesinos,

Christoph von Praun! and Josep Torrellas

HPCA, February 2007

http://iacoma.cs.uiuc.edu

University of Illinois at Urbana-Champaign!IBM Research

Colorama: Ar chitectural Support for Data-Centric Synchr onization · 2007. 9. 14. · Luis Ceze Colorama February 2007 NYV\W Colorama: Ar chitectur e Support for DCS ¥ Main advantage:

Documents