From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sun, 13 Sep 1998 13:05:25 +0200 (MEST)

Re: Time for a stable version release ?

Hi !

> > A single global lock is IMHO not good.
> I didn't think that's what they were suggesting ... just a per-visual
> lock...

That's how I understood it. However ...

> Yeah, making it per-directbuffer rather than per-visual is a better idea
> anyway.

So we agree :-). I see no reason, why we couldn't use multiple buffers at
the same time.

My idea is, that LibGGI internally should have a ggiDrawfunction-Lock
which gets set/reset be running drawing functions, while they are doing
critical things, where no others may interfere. 

And example would be a net-target assembling a packet in some buffer that
would also be used by another thread.

As the locking functions are set within that locking structure, we can 
make up any needed behaviour for the locking like

- a DrawLock also locks all DBs, while DBs can be locked individually
- the DrawLock can be implemented with a kernelside "delayed UnLock", when
  the Accel is ready again
- ...

So o.k. let's propose something, so we can talk about it:

struct ggi_lock {

	struct lockfunctions {
		int (*lock)(ggi_visual_t vis,struct ggi_lock *lock);
		int (*unlock)(ggi_visual_t vis,struct ggi_lock *lock);
		int (*trylock)(ggi_visual_t vis,struct ggi_lock *lock);
	}
	int locktype;	/* In case someone wants to build a generic handler */
	union lockdatastructs {
		pthread_mutex_t mutex;
		spinlock	slock;
		kernel_shared_lock	kslock;
		int		naive_lock;
		void 		*whatever;
		struct ggi_lock *for_"shared"_locks;
	}
}

Would that be feasible ?

I think there should be one lock in the visual for drawing operations,
and one per directbuffer.

Moreover we should provide some sets of "standard" locking functions
for the two common cases of a simple lock or a "redirected lock" that
would be used for coupling two locks.

O.K. - comments ?

Oh - yes and it would be good to either kind of document _ggiDebugState
for target programmers or have a macro for that, as one might want to
implement error-checking locking functions for targets that otherwise
don't do locking to aid application-debugging.

> > Ah yes - and things like CheckLock might be useful, too - right ?
> I'd suggest ggiDBTryLock().

Yes. That was what I meant.

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =