On Tue, 14 Aug 2007 10:00:47 -0700, dick <d...@hotmail.com>
wrote:

>
>Is there any C syntax extension that support multi-thread like Java
>syntax?
>or how can I use  C Macro to hide the OS routine call in C program?
>
>I don't like the style:
>fun(...)
>{
>p();
>.
>.
>.
>v();
>}
>
>I want to use
>syn fun(...)
>{
>.
>.
>.
>}

Why do you want to use critical sections in the first place ?

I would consider critical sections harmful. A program with lots of
critical sections cluttered all over the program is a sign of bad
architectural design, which is also prone to priority inversion and
other problems. 

With proper data structure design and proper partitioning of
functionality into (server)tasks, the need for critical sections would
be greatly reduced.

In single processor embedded systems, disabling the interrupts (which
also disables task switching), doing 2-4 lines of critical code and
then enabling interrupts should satisfy the needs for critical
sections. If this is not enough, you should look at your architectural
design.

Paul

On Thu, 16 Aug 2007 13:10:35 +0300, Paul Keinanen <k...@sci.fi>
wrote:

>On Tue, 14 Aug 2007 10:00:47 -0700, dick <d...@hotmail.com>
>wrote:
>
>>
>>Is there any C syntax extension that support multi-thread like Java
>>syntax?
>>or how can I use  C Macro to hide the OS routine call in C program?
>>
>>I don't like the style:
>>fun(...)
>>{
>>p();
>>.
>>.
>>.
>>v();
>>}
>>
>>I want to use
>>syn fun(...)
>>{
>>.
>>.
>>.
>>}
>
>Why do you want to use critical sections in the first place ?
>
>I would consider critical sections harmful. A program with lots of
>critical sections cluttered all over the program is a sign of bad
>architectural design, which is also prone to priority inversion and
>other problems. 
>
>With proper data structure design and proper partitioning of
>functionality into (server)tasks, the need for critical sections would
>be greatly reduced.
>
>In single processor embedded systems, disabling the interrupts (which
>also disables task switching), doing 2-4 lines of critical code and
>then enabling interrupts should satisfy the needs for critical
>sections. If this is not enough, you should look at your architectural
>design.

How many times have you had the opportunity to re-architect a badly
designed system?



>Paul

Paul Keinanen wrote:
> On Tue, 14 Aug 2007 10:00:47 -0700, dick <d...@hotmail.com>
> wrote:
>
> >
> >Is there any C syntax extension that support multi-thread like Java
> >syntax?
> >or how can I use  C Macro to hide the OS routine call in C program?
> >
> >I don't like the style:
> >fun(...)
> >{
> >p();
> >.
> >.
> >.
> >v();
> >}
> >
> >I want to use
> >syn fun(...)
> >{
> >.
> >.
> >.
> >}
>
> Why do you want to use critical sections in the first place ?
>
> I would consider critical sections harmful. A program with lots of
> critical sections cluttered all over the program is a sign of bad
> architectural design, which is also prone to priority inversion and
> other problems.
>
> With proper data structure design and proper partitioning of
> functionality into (server)tasks, the need for critical sections would
> be greatly reduced.
>
> In single processor embedded systems, disabling the interrupts (which
> also disables task switching), doing 2-4 lines of critical code and
> then enabling interrupts should satisfy the needs for critical
> sections. If this is not enough, you should look at your architectural
> design.
>
> Paul

So you treat C as an abstract ASM or a machine generator?

I know why C is an OLD language.  Just because the C community is not
willing to improve it.
C evolve slower than English.

Paul Keinanen wrote:
> On Tue, 14 Aug 2007 10:00:47 -0700, dick <d...@hotmail.com>
> wrote:
>
> >
> >Is there any C syntax extension that support multi-thread like Java
> >syntax?
> >or how can I use  C Macro to hide the OS routine call in C program?
> >
> >I don't like the style:
> >fun(...)
> >{
> >p();
> >.
> >.
> >.
> >v();
> >}
> >
> >I want to use
> >syn fun(...)
> >{
> >.
> >.
> >.
> >}
>
> Why do you want to use critical sections in the first place ?
>
> I would consider critical sections harmful. A program with lots of
> critical sections cluttered all over the program is a sign of bad
> architectural design, which is also prone to priority inversion and
> other problems.
>
> With proper data structure design and proper partitioning of
> functionality into (server)tasks, the need for critical sections would
> be greatly reduced.
>
> In single processor embedded systems, disabling the interrupts (which
> also disables task switching), doing 2-4 lines of critical code and
> then enabling interrupts should satisfy the needs for critical
> sections. If this is not enough, you should look at your architectural
> design.
>
> Paul

So you treat C as an abstract ASM or a machine code generator?

I know why C is an OLD language.  Just because the C community is not
willing to improve it.
C evolve slower than English.

On Thu, 16 Aug 2007 08:19:22 -0700, dick wrote:

> 
> Paul Keinanen wrote:
>> On Tue, 14 Aug 2007 10:00:47 -0700, dick <d...@hotmail.com>
>> wrote:

>> Why do you want to use critical sections in the first place ?
>>
>> I would consider critical sections harmful. A program with lots of
>> critical sections cluttered all over the program is a sign of bad
>> architectural design, which is also prone to priority inversion and
>> other problems.
>>
>> With proper data structure design and proper partitioning of
>> functionality into (server)tasks, the need for critical sections would
>> be greatly reduced.
>>
>> In single processor embedded systems, disabling the interrupts (which
>> also disables task switching), doing 2-4 lines of critical code and
>> then enabling interrupts should satisfy the needs for critical
>> sections. If this is not enough, you should look at your architectural
>> design.
>>
>> Paul
> 
> So you treat C as an abstract ASM or a machine code generator?
> 
> I know why C is an OLD language.  Just because the C community is not
> willing to improve it.
> C evolve slower than English.

First, Paul is describing how you can handle certain problems regardless
of the language being used. So I don't understand your reply in this
context.

Second, you are not totally wrong when you see a relationship between
C and ASM: C was developed as high level 'assembly' for building the Unix
operating system.

Third, you may regard the low-level look-and-feel of C as a disadvantage,
but right for the above mentioned use, e.g. OSes but also embedded
systems, it is advantageous to have precise control: C statements do
what they must do and nothing else.

Of course this may not be what you want, but then you are free to use any
other tool that suits you well, and it is no reason to start
mocking about a presumed "C community". Have a look at comp.std.c and see
how different people have many different opinions on the directions of the
C language: a monolithic "C community" with a single voice denying
change does not exist. 


Rob Windgassen