On Tue, 14 Aug 2007 10:00:47 -0700, dick <dick_12345678@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
Shall I move from C to Java?
Started by ●August 14, 2007
Reply by ●August 16, 20072007-08-16
Reply by ●August 16, 20072007-08-16
On Thu, 16 Aug 2007 13:10:35 +0300, Paul Keinanen <keinanen@sci.fi> wrote:>On Tue, 14 Aug 2007 10:00:47 -0700, dick <dick_12345678@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
Reply by ●August 16, 20072007-08-16
Paul Keinanen wrote:> On Tue, 14 Aug 2007 10:00:47 -0700, dick <dick_12345678@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. > > PaulSo 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.
Reply by ●August 16, 20072007-08-16
Paul Keinanen wrote:> On Tue, 14 Aug 2007 10:00:47 -0700, dick <dick_12345678@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. > > PaulSo 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.
Reply by ●August 16, 20072007-08-16
On Thu, 16 Aug 2007 08:19:22 -0700, dick wrote:> > Paul Keinanen wrote: >> On Tue, 14 Aug 2007 10:00:47 -0700, dick <dick_12345678@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