Reply by karthikbalaguru●September 8, 20092009-09-08
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
Reply by Vladimir Vassilevsky●September 7, 20092009-09-07
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
Reply by Boudewijn Dijkstra●September 7, 20092009-09-07
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/
Reply by Ari Okkonen●September 7, 20092009-09-07
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/