Re: [9fans] semaphores

Re: [9fans] semaphores

[Russ Cox]

> Should that be `typedef struct Semaphore Sema;' in order for s->data to
> work?

probably struct Sema, but yeah.
i haven't actually compiled the code.
like i said, as soon as i wrote it
i discovered i didn't need it.

Re: [9fans] Semaphores

[Steve Simon]

http://cs.gmu.edu/cne/modules/ipc/pink/swsem.html

This is very plan9 centric but relates to implementing spinlocks
on a multiprocessor system - bit more advanced but a very salient
lesson in the car that is needed to implement these things properly.

http://plan9.bell-labs.com/cm/cs/cstr/158e.ps.gz

-Steve

Re: [9fans] Semaphores

[Russ Cox]

You can't use signals for wakeup on Plan 9.
There is no sigprocmask to turn off note delivery
(so no atomic sections) and no sigsuspend
(so no atomic check a condition and go to sleep).

Instead you need to use rendezvous(2).

For a good example of using rendezvous to
do sleep and wakeup, read the implementation
of qlock, in /sys/src/libc/9sys/qlock.c.  Everywhere
it says (*_rendezvousp) just pretend it says
rendezvous.  (The thread library replaces the
rendezvous that qlock uses, but that detail is
not relevant here.)

Russ

[9fans] Semaphores

[Joel Salomon]

Homework help:  Could someone point me to an explanation of semaphore
implementation?  I'm supposed to implement something very like
semacquire(2) using TAS spinlocks (the professor says it's OK for me
to use lock(2), but not qlock), but in user mode.  He suggests using
signals for wakeup.

I'm looking at /sys/src/9/port/sysproc.c and /sys/doc/sleep.* not
quite understanding either.  Is there a readable description of
queueing on a semaphore in the literature somewhere?  Google's mostly
turning up assembler-heavy linux kernel one-upsmanship.

--Joel
-- 
In googlis non est, ergo non est.

Re: [9fans] semaphores

[Ralph Corderoy]

Hi Russ,

> I figured I'd toss them out for others and to see if anyone noticed
> any problems.
> ...
> typedef struct Sema Sema;
> struct Semaphore {
>       QLock data;
>       QLock wait;
>       int n;
>       int need;
> };
>
> void
> incsema(Sema *s, int c)
> {
>       qlock(&s->data);

Should that be `typedef struct Semaphore Sema;' in order for s->data to
work?


Ralph.

Re: [9fans] semaphores

[Ronald G Minnich]

On Tue, 15 Jan 2002, Scott Schwartz wrote:

> A previous edition's malloc used a pipe with a byte in it as a semaphore.
> I thought that was a lovely solution, given shared file descriptors.

those are great if you have a long time to wait, I use them too. But
memory-based ones like Russ posted are also mighty handy!

ron

Re: [9fans] semaphores

[Boyd Roberts]

Scott Schwartz wrote:
> A previous edition's malloc used a pipe with a byte in it as a semaphore.

I wrote a POP client/daemon on unix that kept the password in a pipe
to minimise the probability of it ending up in a core dump.

Of course on plan 9 and inferno there are no cores -- another plus.

Re: [9fans] semaphores

[nigel]

[-- Attachment #1: Type: text/plain, Size: 39 bytes --]

As does the Lock module in Inferno.


[-- Attachment #2: Type: message/rfc822, Size: 1435 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] semaphores
Date: Tue, 15 Jan 2002 22:54:56 -0500
Message-ID: <20020116035456.13985.qmail@g.bio.cse.psu.edu>

A previous edition's malloc used a pipe with a byte in it as a semaphore.
I thought that was a lovely solution, given shared file descriptors.

Re: [9fans] semaphores

[Scott Schwartz]

A previous edition's malloc used a pipe with a byte in it as a semaphore.
I thought that was a lovely solution, given shared file descriptors.

[9fans] semaphores

[Russ Cox]

I just wrote these for a porting project and
then discovered that I didn't need them.
However, they seem a little subtle to me
(I gave up the first couple times I tried)
so I figured I'd toss them out for others
and to see if anyone noticed any problems.

Russ

/*
 * Semaphore support.
 *
 * The data QLock could be a Lock if you care;
 * it protects the n and need values.
 *
 * The wait QLock manages the line of people waiting to
 * acquire the semaphore.  If you manage to qlock it,
 * it's your turn.  If n isn't big enough for you, record
 * your needs and rendezvous on the Sema; once incsema
 * makes n big enough, it will rendezvous with you.
 */
typedef struct Sema Sema;
struct Semaphore {
	QLock data;
	QLock wait;
	int n;
	int need;
};

void
incsema(Sema *s, int c)
{
	qlock(&s->data);
	s->n += c;
	if(s->need > 0 && s->n >= s->need){
		rendezvous(s, 0);
		s->need = 0;
	}
	qunlock(&s->data);
}

void
decsema(Sema *s, int c)
{
	qlock(&s->wait);
	qlock(&s->data);
	if(s->n < c){
		s->need = c;
		qunlock(&s->data);
		rendezvous(s, 0);
		qlock(&s->data);
	}
	assert(s->n >= c);
	s->n -= c;
	qunlock(&s->data);
	qunlock(&s->wait);
}

int
candecsema(Sema *s, int c)
{
	int ret;

	if(!canqlock(&s->wait))
		return 0;
	qlock(&s->data);	/* won't block for long */
	if(s->n >= c){
		ret = 1;
		s->n -= c;
	}else
		ret = 0;
	qunlock(&s->data);
	qunlock(&s->wait);
	return ret;
}