data consistency & data store fesa advanced. agenda 2 problems with previous framework more...

Data consistency &

data store

FESA Advanced

Agenda

2

Problems with previous framework

More problems with the new CPUs

FESA 3 solutions

Fields types

Field type decision trees

Typical prioritieswe typically give a lower prio to the server threads

E.g. RT around 50 and server around 25

Sometimes, we give even lower prio for some properties (FESA 2.10 background props)

3

Settings problem

4

Datastore

Server writes new settings

RT writes settings in HW

The RT uses inconsistent settings

Inconsistent

Datastore

Server writes new settings

RT writes settings in HW

Inconsistent

The RT uses consistent settings

set

set

Acquisition problem

5

Datastore

Server updates clients

RT writes acquisition

Datastore

Server updates clients

RT writes acquisition

The server sends consistent data

The server sends inconsistent data

Inconsistent

Agenda

6

Problems with previous framework

More problems with the new CPUs

FESA 3 solutions

Fields types

Field type decision trees

New CPUNew problems

Intel Core 2 DUO L7400 – 2 cores w/o hyperthreading

2 cores 2 threads run in parallel whatever the prio

7

Datastore

Server writes new settings

RT writes settings in HW

Inconsistent

The RT uses inconsistent settings

Inconsistent

Similar problem for the acquisition case

Playing with prio no longer helps with data races

set

Agenda

8

Problems with previous framework

More problems with the new CPUs

FESA 3 solutions

Fields types

Field type decision trees

FESA 3 solutionsSettings

Settings flow as defined in FESA 3 is

High-level Server part RT part Hardware

Double-buffer mechanism to protect against data races

9

Datastore

Server writes new settings

RT writes settings in HW

set

InconsistentOK

RT sync

OK

The RT uses consistent settings

RT sync done in the RT part

Very cheap pointer swapping very little jitter introduced

pending buffer (server)

active buffer (RT)

FESA 3 solutionsAcquisition

10

Acquisition flow as defined in FESA 3 is

Hardware RT part Server part High-level

Rolling-buffer mechanism to protect against data races

Uses the cycle-stamp to select the buffer

Implementation hidden you don’t have access to the other buffers

Datastore

Updates for XServer updates clientsRT writes acquisition

Data for cystamp XCystamp Y

Z

Discards data for X

The clients receive consistent acquisitions

Agenda

11

Problems with previous framework

More problems with the new CPUs

FESA 3 solutions

Fields types

Field type decision trees

Field typesThere are 5 types of fields

Configuration

Setting

Unshared setting

Acquisition

Generic

Configuration field Read-only from anywhere

Default field in the configuration section

12

Field typesSetting field

Shared and data-consistent (double-buffer)

Read-write from server

Read-only from RT

Default field in the setting section

Buffer swap by RT part

Unshared setting fieldNot visible from RT

Setting field’s attribute “shared” = false

13

Field typesAcquisition field

Shared and data-consistent (rolling-buffer)

Read-only from server

Read-write from RT

Default field in the acquisition section

Works with the cycle-stamp in the context

Generic fieldAccessible from anywhere and without any protection

Any field’s attribute “data-consistent” = false

Should be used for private fields only

14

An example6 fields – all int32_t

1 configuration field – configField

3 setting fieldsserverField – a server only field (i.e. not shared)

sharedField – a double-buffer field

unprotectedField – a generic field w/o protection

2 acquisition fieldsrollingField – a rolling-buffer field

rtField – a generic field w/o protection (RT use only)

15

An exampleDesign

16

An exampledevice.h

class Device : public fesa::AbstractDevice {public:

Device();

ConfigFieldScalar<int32_t> configField;SettingFieldScalar<int32_t> serverField;SettingFieldScalar<int32_t> sharedField;GenericFieldScalar<int32_t> unprotectedField;AcqFieldScalar<int32_t> rollingField;GenericFieldScalar<int32_t> rtField;

};

An exampleDevice

constructorDevice::Device() :configField("configField",this),serverField("serverField",true, false, this, true,

false),sharedField("sharedField",true, false, this, true,

true),unprotectedField("unprotectedField",true, this,

true),rollingField("rollingField",true, this, false),rtField("rtField",true, this, false)

{}

Note: double-buffer fields and unshared fields have same impl. Only the last arg is different

Rolling buffer depth

configurationRolling buffer’s size in the instantiation file

Minimum 3 slots

Maximum deps on the FEC memory

Agenda

20

Problems with previous framework

More problems with the new CPUs

FESA 3 solutions

Fields types

Field type decision trees

Which setting field?

Do I need to access the field from the

RT part?

Setting field with @shared=false

Do I need to write into the field from

the RT part?

Is the field private to the RT part?

Setting field with @data-

consistent=false

Setting field with @data-

consistent=false

Setting field with default values

N Y

N Y

N Y

You must provide your own data

protection mechanism

ǃ

Which acquisition field?

Is the field private to the RT part?

Acquisition field with @data-

consistent=false

Do I need to keep the value from the

previous execution?

Acquisition field with default values

2 separate fields: 1 private & 1 w/o

history

Y N

Y N

start over for each

field