How do you want to access shared resources?

We need opinions of embedded or real-time software designers
on language features for shared resource protection.

We are improving our toolset for development of embedded and real-time
(and other similar) software. Our toolset includes a graphical
programming tool and a configurable real-time kernel. We are now
introducing a shared resource protection mechanism to our kernel.
We need to add some notation to our graphical (state diagram) language
to express the use of protected resources. The choice of syntax may 
have a significant impact on ease of use, flexibility, clarity of 
expression, risk of error, and perhaps other important considerations.

There are basically two ways to express locking in programming
languages. We can call them structured and unstructured locking.

In structured locking blocks of code are marked to access protected
resources. These blocks must be well nested with each other and
other program structures. This means that the set of locked items is 
defined by the position in the program, it does not depend on the 
path used to reach the position (excluding functions). 

In unstructured locking protected resources are first locked and
finally locked by execution of specific instructions. This means
that the set of locked items depends on the locking and unlocking 
instructions along the way to the current position.

Whether we should offer the structured or the unstructured locking 
is a fundamental design decision we have to do. We want to choose
the syntax that best serves the needs of software designers.

* What kind of experiences do you have with either or both kinds
  of locking syntaxes?

* What positive and negative implications do you see in these
  syntaxes, and how important do you think these implications are?

In addition we would like to have your opinion on:

* separate read and update locks

* compile-time checking of resource accesses without locking

Finally, what else should be considered regarding the features and
needs related to resource protection and locking?

Regards,

Ari Okkonen
OBP Research Oy
http://www.obp.fi/

Op Mon, 07 Sep 2009 10:33:48 +0200 schreef Ari Okkonen  
<ari.okkonen@obp.fi>:
> We need opinions of embedded or real-time software designers
> on language features for shared resource protection.

Resources should not be shared, they should be encapsulated by the  
resource owner and hidden behind an interface.  This promotes loose  
coupling, software reuse and structured programming.

> We are improving our toolset for development of embedded and real-time
> (and other similar) software. Our toolset includes a graphical
> programming tool and a configurable real-time kernel. We are now
> introducing a shared resource protection mechanism to our kernel.
> We need to add some notation to our graphical (state diagram) language
> to express the use of protected resources. The choice of syntax may have  
> a significant impact on ease of use, flexibility, clarity of expression,  
> risk of error, and perhaps other important considerations.
>
> There are basically two ways to express locking in programming
> languages. We can call them structured and unstructured locking.

Locking is inherently error-prone, often ruins real-time predictability,  
potentially causes deadlocks which can be hard to debug.

> In structured locking blocks of code are marked to access protected
> resources. These blocks must be well nested with each other and
> other program structures. This means that the set of locked items is  
> defined by the position in the program, it does not depend on the path  
> used to reach the position (excluding functions).

In other words, it is like the Java Language "synchronized" keyword.  It  
does not guarantee that a lock is warranted nor that an access somewhere  
else uses the same lock reference.

> In unstructured locking protected resources are first locked and
> finally [unlocked] by execution of specific instructions. This means
> that the set of locked items depends on the locking and unlocking  
> instructions along the way to the current position.

There is no fundamental difference between the two.  The implementation of  
structured locking will have to make use of unstructured locking  
techniques anyway.  The only difference is the way in which the pairing of  
lock/unlock is guaranteed/checked/debugged.

> Whether we should offer the structured or the unstructured locking is a  
> fundamental design decision we have to do. We want to choose
> the syntax that best serves the needs of software designers.
>
> * What kind of experiences do you have with either or both kinds
>   of locking syntaxes?

Either way you have to take care, and either way if you do complex stuff  
it is easy to miss a critical detail.  Neither makes it particularly easy  
to guarantee that a resource is locked when used.

> * What positive and negative implications do you see in these
>   syntaxes, and how important do you think these implications are?
>
> In addition we would like to have your opinion on:
>
> * separate read and update locks

It complicates the question of how to be reasonably sure that a resource  
is locked correctly when used.  In stead, the owner of the resource should  
service requests and choose when to service which kind of request  
according to a documented algorithm.

> * compile-time checking of resource accesses without locking

If you allow arbitrary code fragments in your state machine language, then  
you will need an intelligent (=expensive) parser to enforce correctness.

> Finally, what else should be considered regarding the features and
> needs related to resource protection and locking?

Consider direct asynchronous message passing as a means of inter-process  
communication.  UML state machines already provide the syntax to send and  
receive messages a.k.a. events a.k.a. signals.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Ari Okkonen wrote:

> We need opinions of embedded or real-time software designers
> on language features for shared resource protection.
> 
> We are improving our toolset for development of embedded and real-time
> (and other similar) software. Our toolset includes a graphical
> programming tool and a configurable real-time kernel. We are now
> introducing a shared resource protection mechanism to our kernel.
> We need to add some notation to our graphical (state diagram) language
> to express the use of protected resources. The choice of syntax may have 
> a significant impact on ease of use, flexibility, clarity of expression, 
> risk of error, and perhaps other important considerations.
> 
> There are basically two ways to express locking in programming
> languages. We can call them structured and unstructured locking.
> 
> In structured locking blocks of code are marked to access protected
> resources. These blocks must be well nested with each other and
> other program structures. This means that the set of locked items is 
> defined by the position in the program, it does not depend on the path 
> used to reach the position (excluding functions).
> In unstructured locking protected resources are first locked and
> finally locked by execution of specific instructions. This means
> that the set of locked items depends on the locking and unlocking 
> instructions along the way to the current position.
> 
> Whether we should offer the structured or the unstructured locking is a 
> fundamental design decision we have to do. We want to choose
> the syntax that best serves the needs of software designers.
> 
> * What kind of experiences do you have with either or both kinds
>  of locking syntaxes?
> 
> * What positive and negative implications do you see in these
>  syntaxes, and how important do you think these implications are?
> 
> In addition we would like to have your opinion on:
> 
> * separate read and update locks
> 
> * compile-time checking of resource accesses without locking
> 
> Finally, what else should be considered regarding the features and
> needs related to resource protection and locking?


The atomic access is the property of the interface of the resource, not 
the responsibility of the application code which uses the resource. No 
special syntax should be needed at the application level.

The explicit locking is very prone to mistakes, no matter how you 
implement it. There should be no concept of locking at the level of the 
application development. There are two solutions to the problem:

1. An object should be accessible from one thread/process only, unless 
declared as <shared>. The atomic access is provided by OS then.

2. Toss the objects from one thread to another using the object passing 
mechanism provided by OS.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Sep 7, 1:33=A0pm, "Ari Okkonen" <ari.okko...@obp.fi> wrote:
> We need opinions of embedded or real-time software designers
> on language features for shared resource protection.
>
> We are improving our toolset for development of embedded and real-time
> (and other similar) software. Our toolset includes a graphical
> programming tool and a configurable real-time kernel. We are now
> introducing a shared resource protection mechanism to our kernel.
> We need to add some notation to our graphical (state diagram) language
> to express the use of protected resources. The choice of syntax may
> have a significant impact on ease of use, flexibility, clarity of
> expression, risk of error, and perhaps other important considerations.
>
> There are basically two ways to express locking in programming
> languages. We can call them structured and unstructured locking.
>
> In structured locking blocks of code are marked to access protected
> resources. These blocks must be well nested with each other and
> other program structures. This means that the set of locked items is
> defined by the position in the program, it does not depend on the
> path used to reach the position (excluding functions).
>
> In unstructured locking protected resources are first locked and
> finally locked by execution of specific instructions. This means
> that the set of locked items depends on the locking and unlocking
> instructions along the way to the current position.
>
> Whether we should offer the structured or the unstructured locking
> is a fundamental design decision we have to do. We want to choose
> the syntax that best serves the needs of software designers.
>
> * What kind of experiences do you have with either or both kinds
> =A0 of locking syntaxes?
>
> * What positive and negative implications do you see in these
> =A0 syntaxes, and how important do you think these implications are?
>
> In addition we would like to have your opinion on:
>
> * separate read and update locks
>
> * compile-time checking of resource accesses without locking
>
> Finally, what else should be considered regarding the features and
> needs related to resource protection and locking?
>
> Regards,
>
> Ari Okkonen
> OBP Research Oyhttp://www.obp.fi/

Are you looking for a Multicore processor environment ?
Nowadays, graphic engines and network processors use multicore
processor.
In those cases, You need to design it to co-exist with the hardware
design.
It would be more closely tied with a scheduler(Hardware).

Best Regards,
Karthik Balaguru