nanogui: Thread-safety, wrapping globals in structs, RTEMS
Subject:
Re: Thread-safety, wrapping globals in structs, RTEMS
From:
"Thompson, Brent" ####@####.####
Date:
20 Dec 2000 15:30:58 -0000
Message-Id: <3A40D12D.7020903@nlc.com>
I've been working on porting Microwindows (both Mwin32 and
NanoX) to a VxWorks platform. VxWorks is a small, thread-based,
shared-namespace kernel, and it sounds like we share some of the
same issues as RTEMS.
"Greg Haerr" ####@####.#### wrote:
>
> : RTEMS has provisions for giving each rtems_task a private copy
> : of global variables, and I haven't yet played with this and so I haven't
> : yet identified the gotchas I'd encounter by trying to privatize nano-X
> : globals.
>
> I'd like to get your list of globals used. There are two basic
> types, static's per file and shared globals. I've had some
> thought on moving some of the g_ globals in engine/devopen.c into
> the PSD struct, for various reasons. Others, including all the
> statics, are really global and shouldn't be per-task nor should
> they affect the operation of Microwindows in a multi-threaded
> environment, unless you're wanting to be able to draw simultaneously
> from multiple tasks.
>
> : Much more elegant would be the wrapping of globals into structs. Has
> : anyone tried tackling this, or given thought to doing so? Or how to do so
> : without destroying everything? and if not, is anyone interested in
> : giving it a shot with me? I'd start in about two weeks.
>
> I like the idea, but what really does wrapping into a struct buy
> us from a multi-tasking perspective?
I did successfully get the engine code "de-globalized" by
moving all of the globals (and statics) into the PSD.
What this gets you (in my case, anyway) is the chance to
support multiple independent screen devices with just a
little more init code (ie, each screen will have its own
root window, fore/back-ground colors, cursors, clipping regions,
etc.). I do have this code available, but have not yet
sent in any patches (see next Paragraph for why!). If you
would like to see this code, just ask and I'll package it
up for you.
But when I moved onto the Mwin32 and NanoX code, there was
a *lot* more work to be done. Especially problematic are
the Win32 calls which don't pass in any pointers, so you
*have* to use globals to get anywhere. So I dropped work
on this and am re-evaluating how to support multiple
independent screens.
As for making Microwindows thread-safe (which is what
Kaben was originally asking for -- I think! ;-) I don't
think you necessarily need to "de-globalize" the code. As
long as your system can share globals, we just need a
semaphore type of lock/unlock every time we access one of
the globals (or, at a more gross level, every time we enter/leave
a Microwindows function). I think it would be useful to
add some access control functions (ie, semaphore lock/unlock)
to all of the Microwindows functions. By default, they
can just be empty functions (and so, with compiler optimization,
would be optimized out and the code should work just as
fast as it does today). But if an implementor over-rode these
functions with real semaphore lock/unlocks for a particular
OS, then you would have a multi-tasking thread-safe
Microwindows implementation!
I'm not a Linux-guru, but how do Linux handle multiple
Microwindows processes? I have experience in OS-9 (a real-time
process-oriented OS) and in that environment we would package
up all of the globals/statics to be shared into a "data module"
which all of the apps could then link to and use (with proper
semaphore access control, of course!) Is this what you
mean, Kaben? In this case, you would need both the
"de-globalization" and semaphore control added to Microwindows.
Well, that's enough of me yapping for now. What do you
guys think?
BAT
--
Brent A. Thompson, Next Level Communications <www.nlc.com>
1776 22nd Street #100, West Des Moines, IA 50266-1444
EMail: ####@####.#### Phone: (515)991-3853
