From: Rob McCool <robm@netscape.com>
Newsgroups: netscape.devs-nsapi
Subject: Re: Help with Critical section syntax
Date: Mon, 28 Oct 1996 14:17:35 -0800

> today I am trying to understand and use the built in Critical section
> functions. There are eight functions and about that many lines of
> explanation in the Netscape programmer's guide. I am not understanding
> how to lock a section of code to make it single threading. Does anyone
> have any example code? Or, can you just tell me in what order these
> eight functions needs to be called?
> 
> Do the variables have to be global? Do they need to be initialized in
> a special init function, or can they just be initialized at the
> beginning of the regular authorization funtion?

In general, the variables or sockets you would protect with a critical
section would be global. The critical section variable would also be
global. Hitesh gave you a pointer about how to use condvars, here's a
simple example of using just a critical section:


static CRITICAL countcr;
static int count;

int my_initfunc(pblock *pb, Session *sn, Request *rq)
{
  count = 0;
  countcr = crit_init();
  return REQ_PROCEED;
}
int my_otherfunc(pblock *pb, Session *sn, Request *rq)
{
  crit_enter(countcr);
  ++count;
  crit_exit(countcr);
  return REQ_PROCEED;
}

So what happens here is that there's a global counter variable, that's
initialized in my_initfunc. Now, my_otherfunc is just another NSAPI
function, service or authtrans or whatever. In this function, you want
to increase the counter by one for each request that is made to the
server. Because of threading, you can have more than one thread
executing that code at a time.

Suppose you didn't have the critical section there. Then, thread A could
enter my_otherfunc, and hit the ++count line. An increment requires the
thread to read the variable, add one to it, and write it back again. The
problem is, thread A could be interrupted after it reads the variable
but before it adds one or writes it back. Thread B could then run and
increase the count. When thread A runs again, it will then write the
wrong count into the variable because it will not re-read thread B's new
value for it.

The critical section makes sure that the ++count line is only executed
by one thread at a time. When a thread calls crit_enter, it is only
allowed to continue to the ++count line if no other thread is currently
executing the ++count line. If thread A is currently executing ++count,
and thread B calls crit_enter, thread B will not be allowed to run until
thread A executed the crit_exit line.

Hope that helps. If these kinds of concepts are new to you, then you
might want to go poking around for some information on threading,
mutexes, and synchronization.
--
Rob McCool, robm@netscape.com http://home.netscape.com/people/robm/
Stunt Programmer, Netscape Communications Corporation
It was working ten minutes ago, I swear...

Reproduced by permission of the author.