Signal Semaphores

Thread View: amiga.prog

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Russell McOrmond Tue, 21 Jul 1992 03:26

Author: Russell McOrmond
Date: Tue, 21 Jul 1992 03:26

61 lines
2306 bytes

  I'm wondering if anyone has done extensive work with SignalSemaphores under
2.04 (V37) that could let me know what I'm doing wrong with my use of them.
I just put a 'Forbid()/Permit()' pair around all the things
that 'should' have been protected by an ObtainSemaphore/ReleaseSemaphore
pair in some multi-threaded code, and a large number of bugs just 'went away'.   
Since I'd rather that ALL tasks didn't wait, and only those wanting access 
to these structures, I'd rather get things working.

  The program in question runs many different processes, all of which share
the same global variables.  When accessing any of the structures, I had put
semaphore arbitration around the calls. Here's some 'example' code from what
I'm doing:

typedef struct config_struct {
  struct slave_struct mainSlave;
  /* Slaves */
  struct SignalSemaphore listLock;

....

  if((myconfig=AllocMem(sizeof(config),MEMF_CLEAR))) {

....

    InitSemaphore(&myconfig->listLock);

....

int CountSlaves()
{
  slave *aslave;
  int i;

  i=0;

  ObtainSemaphore(&myconfig->listLock);
  Forbid();
  FOREACH_LIST_UNSAFE(&myconfig->slaves,aslave)
    if(aslave!=myconfig) i++;
  END_LIST_UNSAFE;
  Permit();
  ReleaseSemaphore(&myconfig->listLock);
  return(i);
}



  All other calls are exactly the same as the Semaphore calles above.
As mentioned, without the Forbid()/Permit() pair around the calls, everything
crashes very quickly.  P.S. Yes, the InitSemaphore happens very soon after
the memory is allocated, and long before any other semaphore operations are
called.

  Thanks for any help.  The net has always been great for pointing out my
stupid errors so I can quickly move on to getting some real work done! ;-)

---
  Opinions expressed in this message are my Own. I represent nobody else.
  Russell McOrmond  rwm@Atronx.OCUnix.On.Ca Net Support:(613) 230-2282(V.32Bis)
  FidoNet 1:163/109 Amiga-Fido 1:1/109  Current WELMAT 'keeper of sources'.

Re: Signal Semaphores

Author: Jeff Dickson
Date: Thu, 23 Jul 1992 15:56

36 lines
1885 bytes

In article <rwm.711692783@atronx.OCUnix.On.Ca> rwm@atronx.OCUnix.On.Ca (Russell McOrmond) writes:
>
>  I'm wondering if anyone has done extensive work with SignalSemaphores under
>2.04 (V37) that could let me know what I'm doing wrong with my use of them.
>I just put a 'Forbid()/Permit()' pair around all the things
>that 'should' have been protected by an ObtainSemaphore/ReleaseSemaphore
>pair in some multi-threaded code, and a large number of bugs just 'went away'.   
>Since I'd rather that ALL tasks didn't wait, and only those wanting access 
>to these structures, I'd rather get things working.
>
>  The program in question runs many different processes, all of which share
>the same global variables.  When accessing any of the structures, I had put
>semaphore arbitration around the calls. Here's some 'example' code from what
>I'm doing:

I've done extensive work with the signal semaphore stuff, but from Assembly.
You didn't say what C compiler you're using. If an older MANX (i.e. <= 3.6)
then the statement:

>  if((myconfig=AllocMem(sizeof(config),MEMF_CLEAR))) {

would be wrong if sizeof(config) returns a 16 bit integer instead of a 32 bit
which AllocMem expects.

>
>typedef struct config_struct {
>  struct slave_struct mainSlave;
>  /* Slaves */
>  struct SignalSemaphore listLock;
>

And what are you doing here? Redefining what the keyword struct means?

Investigate those items. Next time post how you declare "config".

jeff

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads