From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Mon, 14 Sep 1998 21:49:52 +0200 (MEST)

Re: Time for a stable version release ?

Hi !

> > The locks Andy describes are an integral part of thread safety, as well as

> Yes, I know that. But the question I'm asking is if there's any
> need to lock a _framebuffer_ for threadsafety. 

Yes. At least against accel-calls. For KGI this might even need to be done
at kernel level (unmapping the FB), as some cards crash the bus, if they
are accessed by accel and fb at the same time.

Others are rumored to trash the screen in that case (where I think we could 
live with a kind of "advisory" lock - if you don't use it or ignore it,
well it's your fault ...).

> I perfectly understand
> the need for locks in drawing primitives which may be accessing
> accel registers and other things that may be fscked up by writing
> to them in the wrong order.

Similar things might happen with mixing accel and framebuffer. Thus I 
want them to interlock.

Note that I am using "lock" in a very generic manner here. This is also
why I proposed that complicated lock struct :

Some of those "locks" might be able to turn multiple times.

That is : Multiple threads can lock a DirectBuffer, but a single turn of
the lock suffices to lock out accel access.

> But for the framebuffer we don't need any _locks_, we just need a
> function (ggiEnableDB()) that will block until the accel queue is
> flushed. Making sure that the user doesn't use the drawingprimitives
> between ggiEnableDB() and ggiDisableDB() is NOT our problem.

It might be. In case this heavily interferes with the HW and I think it
doesn't make a difference to just locking drawing primitives against
each other, so we can do that in the same step.

> As I said the only possible problem with multiple processes/threads
> accessing a framebuffer would be on a SMP machine, and I'm really
> in doubt if this can cause trouble on any hardware.

Yes - I see no technical reason, why accessing _the_same_ framebuffer
from different processes would create a problem (thus the multi-turn-locks).
However accessing differnt framebuffers might.

In case of serious problems, we should lock in kernel mode, thus also
catching "evil" applications, for lesser problems (screwed up display and
such), usermode locks might help.

CU,Andy

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