1. Home
  2. Embedded Programming
  3. How do you want to access shared resources?

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

formatting link

Reply to
Ari Okkonen
Loading thread data ...

Op Mon, 07 Sep 2009 10:33:48 +0200 schreef Ari Okkonen :

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.

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

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.

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.

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.

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.

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

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 to
Boudewijn Dijkstra

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 . 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

formatting link

Reply to
Vladimir Vassilevsky

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 to
karthikbalaguru

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.