nanogui: pixmap buffer patch!
Subject:
Re: pixmap buffer patch!
From:
"Aaron J. Grier" ####@####.####
Date:
27 Aug 2002 19:25:10 -0000
Message-Id: <20020827192409.GB27639@aaron.unix.fryenet>
On Tue, Aug 27, 2002 at 10:20:18AM -0600, Jordan Crouse wrote:
> Now, the bad news - the semaphore adds another couple levels of
> complexity to the issue, and in order to do it correctly, we will need
> to include processor specific assembly language to handle the atomic
> read/write operations. This is assuming, of course, that we choose
> not to use an 3rd party library.
I would discourage this choice. all locking operations should either
stick with a specific third-party API (pthreads, for instance,) or be
turned into macros / inline functions so whatever is available can be
plugged in.
there is no need to re-invent the wheel when it comes to locking
primitives. you'll end up duplicating code, and giving yourself
maintenance headaches.
> So in order to increase our performance and control over the shared
> framebuffer, we are going to have to take a slight hit in our
> portability, at least in the near term (until we get a reasonable
> library with all of the needed assembly for our most popular
> processors).
if you go the macro / inline route, the default could be empty
operations, which leaves the portability situation no better or worse
than it currently is.
> Having said all this, I vote that we go ahead and add the code.
> Having a good internal semaphore system would be useful both now, and
> in the future (and it would really make the RTOS guys happy).
pluggable mutex code would make me happy. RTEMS already provides
locking primitives with optional pthreads API, even.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
