nanogui: Multi threads with WIN32 API
Subject:
Re: [nanogui] Multi threads with WIN32 API
From:
Peter Dufault ####@####.####
Date:
21 Nov 2001 19:12:27 -0000
Message-Id: <20011121141417.A80875@hda.hda.com>
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
