nanogui: Thread: Multi threads with WIN32 API

I have an application where I'll use the WIN32 GDI API.  It will be
multi-threaded, though.  What I plan on doing is to restrict all microwindows
to a single thread other than PostThreadMessage, to require that
PostThreadMessage always be sent to
thread 0 or the above mentioned thread,
and to put locking mutexes in the GdRoutines in engine/devlist.c.

Make sense?  See any other gotchas?  Is there a suggested mutex API?
Can I just use the pthread mutex semantics and provide a default
NULL implementation?

Peter

--
Peter Dufault ####@####.####   Realtime development, Machine control,
HD Associates, Inc.               Fail-Safe systems, Agency approval

Peter Dufault wrote:


> Make sense?  See any other gotchas?  Is there a suggested mutex API?
> Can I just use the pthread mutex semantics and provide a default
> NULL implementation?


If you're running on a machine which uses glibc, it would make most 
sense to use posix threads (which glibc provides an implementation of). 
In this case, be careful what version of glibc you use - the threads 
implementation in glibc-2.2.2 is a bit broken, and recursive mutex's in 
particular are completely busted. With a few workarounds, i've been able 
to get my multithreaded app working on an x86 with glibc-2.2.2, but have 
had no luck on a StrongARM. glibc-2.1.3 works well on both platforms. If 
you're running under linux, an alternative is a new posix threads 
implementation being worked on by IBM at 
http://oss.software.ibm.com/developerworks/opensource/pthreads/ . 
Something else to keep in mind is visibility with a debugger. If you're 
using IBM's implementation, you get none, with glibc-2.1.3, you do 
fairly well (on x86), provided your code doesn't terminate threads, and 
with glibc-2.2.2 provides more or less complete visibility.



> 
> Peter
> 
> --
> Peter Dufault ####@####.####   Realtime development, Machine control,
> HD Associates, Inc.               Fail-Safe systems, Agency approval
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 
> 


-- 
Duncan Palmer                                ####@####.####
Software Design Engineer                     Phone:     +353-1-2911561
Silicon and Software Systems                 Fax:       +353-1-2911001

: I have an application where I'll use the WIN32 GDI API.  It will be
: multi-threaded, though.  What I plan on doing is to restrict all microwindows
: to a single thread other than PostThreadMessage, to require that
: PostThreadMessage always be sent to
: thread 0 or the above mentioned thread,
: and to put locking mutexes in the GdRoutines in engine/devlist.c.
: 
: Make sense?  See any other gotchas?  Is there a suggested mutex API?
: Can I just use the pthread mutex semantics and provide a default
: NULL implementation?

Sounds good.  I would like to see the mutex macros be placed
probably somewhere like include/mwtypes.h, and be setup so that
a compile time option turns them on or not.  The macros could likely
use the pthread semantics, and include a macro to declare (or
null-declare) the pthread mutex itself.  For example:

#define DEFINE_MUTEX    ...
#define MUTEX_LOCK(sem) ...
#define MUTEX_UNLOCK(sem) ...

You may have to restrict all of the GdXXX drawing entry points
as well, in engine/*.c, but this would be a great starting point for
getting Microwindows thread-safe.  

Let me know if I can help, I think your method should work.  You may
have to play with SendMessage so that it works sending messages to
another thread, that's a little more complicated.  Also, the GetMessage
list may have to have a private threadID member and only get messages
for that thread, unless you want to duplicate Win32 thread semantics, and
return all messages for all process threads...

Regards,

Greg

On Wed, Nov 21, 2001 at 11:16:11AM -0700, Greg Haerr wrote:
> 
> Sounds good.  I would like to see the mutex macros be placed
> probably somewhere like include/mwtypes.h, and be setup so that
> a compile time option turns them on or not.  The macros could likely
> use the pthread semantics, and include a macro to declare (or
> null-declare) the pthread mutex itself.  For example:
> 
> #define DEFINE_MUTEX    ...
> #define MUTEX_LOCK(sem) ...
> #define MUTEX_UNLOCK(sem) ...

I was thinking more along the lines of this in mwtypes.h:

/* If you have real POSIX threads set HAVE_PTHREADS.
 * To provide your own, set PTHREADS_HEADER to an appropriate include
 * that implements pthread_mutex_{init,destroy,lock,unlock}.
 *
 * Otherwise a NULL non-locking implementation is defined.
 */

#if HAVE_PTHREADS

#if defined(PTHREADS_HEADER)
#include PTHREADS_HEADER
#else
#include <unistd.h>
#ifndef _POSIX_THREADS
#error No pthreads implementation yet feature is specified.
#else
#include <pthread.h>
#endif

#else	/* No pthreads. */

#define pthread_mutex_init(M, A) (0)
#define pthread_mutex_destroy(M) (0)
#define pthread_mutex_lock(M)    (0)
#define pthread_mutex_unlock(M)  (0)
#endif

I like this because we don't have to define a new API.

> 
> You may have to restrict all of the GdXXX drawing entry points
> as well, in engine/*.c, but this would be a great starting point for
> getting Microwindows thread-safe.  

I won't need to since I'm restricting this to the single queue we
have now, and only the functions blocked at the queue will do any
drawing.  As long as the requests going into and out of the queue
are properly locked I should be fine.  I probably will need to
clean up the idle loop waiting for stuff to show up in the queue
to block, I'll think about that.  For starters I'll leave it as
it is and just run it low priority.

> Let me know if I can help, I think your method should work.  You may
> have to play with SendMessage so that it works sending messages to
> another thread, that's a little more complicated.

I'm not a Win32 hacker.  I plan on not using SendMessage, but
I would like it to work reasonably or at least detect unreasonable use.
As I understand it, SendMessage is
a hand shaked message, the calling thread suspends until the
target thread handles the function and then resumes (and is a direct
call when the calling thread is the target thread).  I want
a typical queue where an event occurs and a higher priority event handler
just wants to post the message and continue.

> Also, the GetMessage
> list may have to have a private threadID member and only get messages
> for that thread, unless you want to duplicate Win32 thread semantics, and
> return all messages for all process threads...

I'm just allowing a single thread to have a queue so this shouldn't
apply.  Other threads may post to the thread but with the mutex around
the list insertion / deletions it should be fine.

Someone who knows Win32 thread semantics can suggest a good way to assert
that only a single thread has a queue, and that PostThreadMessage only
sends to that queue or to 0, and maybe some ways of handling SendMessage.

Peter

--
Peter Dufault ####@####.####   Realtime development, Machine control,
HD Associates, Inc.               Fail-Safe systems, Agency approval

: #if HAVE_PTHREADS
: #include ...
: #define mutex_init(M, A) ...
: #define mutex_destroy(M) ...
: #define mutex_lock(M)   ...
: #define mutex_unlock(M)  ...
: #elif HAVE_XTHREADS
: #define mutex_init(M, A) ...
: #define mutex_destroy(M) ...
: #define mutex_lock(M)   ...
: #define mutex_unlock(M)  ...
: #else
: #define mutex_init(M, A) 
: #define mutex_destroy(M) 
: #define mutex_lock(M)   
: #define mutex_unlock(M)  
: #endif

: I like this because we don't have to define a new API.

I agree, we don't want another API, just a simple wrapper 
layer for Microwindows, managed by macros rather than
actual calls for a specific library.

That is, we wrap the pthread functions with
an identical (upper-case) #define, and don't use the
phrase "pthread" in the macro name, so that others that
run Microwindows on other environments don't think
they've got to have pthreads to get threading capabilities.
Also, by forcing a single define per threading library function
name use in a header file, a quick look by anybody can see
exactly which threading calls are used by which threading
library in Microwindows.

In other words, with the above macros, one can quickly
see that all that's required for threading implementation in
Microwindows is an init, destroy, lock and unlock call.
Ideally, the wrapper layer describes simple semantics of the
threading functionality required, rather than the actual
arguments required of pthreads.

In any case, have at it!

Regards,

Greg