How to write threads in C-help please to siva 
Author Message
 How to write threads in C-help please to siva

Hello Gurus,

How to write threads in the C language,....
can you guys throw some light ....on this topic...
i can pickup..

thanks a bunch in advance..

Siva.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Siva K. Gowravaram              205-895-9706 (R)
1302 Lancewood Dr. #D           205-730-3793 (O)
Huntsville, AL 35816



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Sun, 11 May 1997 05:50:45 GMT  
 How to write threads in C-help please to siva

: Hello Gurus,

: How to write threads in the C language,....
: can you guys throw some light ....on this topic...
: i can pickup..

: thanks a bunch in advance..

: Siva.

The following is borrowed from various places. I recently played around
with threads in C and came up with the following. If anyone recognises
bits of code, thanks for the hints guys!

First off: -- what is a thread?

If you want to implement pre-emptively scheduled segments of code in a
single address space, you are going to have fun. You can persuade an
OS to give you a signal when a timer expires, but in general this
will be asynchronous with the rest of the system. You can only sensibly
switch between threads when you can make some guarantees about the state
of the system. An interrupt could occur half way through just about
anything, which could cause problems (excepting places where interrupts
are disabled in the OS kernel). Such doings are therefore deemed tricky,
but it can be done.

Simpler, and adequate for most purposes are co-routines. Co-routines are
co-operatively scheduled, that is they explicitly pass control to one
another, or to some scheduler that then selects another co-routine to
be executed. This will do the business quite cleanly and should be easy
enough to implement, which is what follows below:

Co-routines:
-----------

A co-routine shares memory with all other coroutines in the same process.
All that it requires to run sensibly is a stack. The execution context
of a co-routine could thus be represented in a structure, like:

typedef unsigned long ulong;

struct coroutine {
  jmp_buf r_context;
  ulong   stack[STACKSIZE];

Quote:
};

What is this 'jmp_buf' thing? Well, to switch between coroutines you need
to get hold of the register context of the coroutine. This is not the
intended purpose of these routines, but on most systems it can be done
with the standard library functions setjmp and longjmp. <setjmp.h> ANSI
These routines are designed to allow a swift return from a deeply-nested
function to somewhere a lot further up the stack. Some versions of these
functions 'unwind the stack' as they go, which is not exactly what you
want. The simplest versions store just the machine registers away and
restore them.

jmp_buf is just a typedef for an array of (usually unsigned long) integers
into which the register contents are stored by a call to `setjmp'. Setjmp
returns 0 if this is the first call (storing the context). If a subsequent
longjmp is made, specifying the same jmp_buf, setjmp will return with a
non-zero value. This allows the programmer to define different behaviours
in each case.

eg:
---
#include <stdio.h>
#include <setjmp.h>

main(){
  jmp_buf reg;

  printf("Hello out there!\n");

  if (setjmp(reg) == 0) {
    printf("This is my first time!\n");
    longjmp(reg, 1);    /* 1 is return value from 'setjmp' this time */
    printf("I will never get this far!\n");
  } else {
    printf("Whoops, what was that about flow of control?\n");
  }

  printf("Goodbye!\n");

Quote:
}

--- output:
Should give:
Hello out there!
This is my first time!
Whoops, what was that about flow of control?
Goodbye!
---

You get the idea?
To jump to a point your program (schedule a coroutine), you need to modify
the stack pointer and the program counter. The entry-point for a coroutine
can be arranged to be a function. The name of a function in C gives its
entry point (function pointer) -- that gives you the program counter.
In the structure defined above, space for the stack is given by the array
of ulongs. The 0th word on the stack used by a function stores the PC
at the function call instruction, to be used by the return instruction.
To setup a register state for calling a coroutine we could use something
like:

void coroutine1(void) {
... etc...

Quote:
}

{
  jmp_buf env;

  setjmp(env);  /* Initialise env with some non-{*filter*}*/
  env[JB_PC] = (ulong)corotine1;
  env[JB_SP] = (ulong)&stack[STACKSIZE-2];  /* leave space for PC */

  ...

  longjmp(env);         /* et viola */

Quote:
}

By producing a list of structures containing the stack and jmp_buf for
a number of coroutines, bingo -- the core of a coroutines system.

The problem is, what are JB_PC and JB_SP. These are not ANSI, but many
systems define them anyway in <setjmp.h>. These are indexes into the
jmp_buf array for where the PC and SP are stored. If they are not defined,
you will need to find them out. This is left as an exercise to the reader :-)

Note:

        i) If longjmp unwinds the stack, you may have problems. If the
           above method does not work, try _setjmp and _longjmp. These
           may be the more basic versions on some systems.

        ii) The context to which longjmp returns may not preserve the
            value of stack-automatic variables at the setjmp call.

eg:
a = 2;
if (setjmp(env)==0)
  a = 5;
else
  printf("%d\n", a);
--- output
5
---
           this makes perfect sense considering the flow of control, but
           may mislead. Also remember, if you change the stack pointer,
           all automatics (unless in registers) will no longer make any
           sense whatever.

        iii) I have not managed to get the above scheme working on a Sparc.
           The stack on a sparc is implemented on the processor using
           a 'register window' scheme. Changing the SP has some wierd effects
           therefore. Without reaching for a hardware or assembly programming
           manual, I do not know what is going on. It sort of works, but then
           at some points, your data stored in automatics gets corrupted. I
           presume this occurs when the stack (on chip) is flushed to memory.
           It may be possible to fix this if I knew better what was going
           on.

I hope this helps.  :-)

Cheers
        Don

 ----------------------------------------------------

| Scalable Systems and Algorithms Group              |
| School of Computer Studies  ---------------------- |
| University of Leeds        | tel: (+44) 532 335436 |
| Leeds, W. Yorkshire        | fax: (+44) 532 335468 |
| UK                          ---------------------- |
 ----------------------------------------------------  
``As if one could kill time without injuring
  eternity'' (H. Thoreau)



Tue, 20 May 1997 19:18:43 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Please help...writing on the main dialog window from a thread

2. Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!

3. Please help!!!!Please help!!!!Please help!!!!

4. Newbie: separate big .cs file into small .cs files

5. Please Help me to write a function!!!!!

6. PLEASE READ: Help in writing a program (fwd)

7. File Reading/Writing (PLEASE HELP)

8. Please help me to write a C routine

9. Don't write: "Please Help!"

10. help with readin/writing to a file, please

11. I nee your help please write me again!!!

12. Please help with writing a function.

 

 
Powered by phpBB® Forum Software