public inbox for
 help / color / mirror / Atom feed
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: 'Ross Johnson' <>,
	"Craig A. Vanderborgh" <>
Subject: RE: Trouble with mutex/cond destroy on WINCE 3.0
Date: Wed, 26 Feb 2003 14:32:00 -0000	[thread overview]
Message-ID: <> (raw)

Hi Ross,

It might not be enough to simply test for the existence of a
function using dynamic loading on win32... Case in point:
Win95 did not support TryEnterCriticalSection at all, whereas
Win98 added the method, but did not implement it (i.e. returned
function not supported if you called it...)

-----Original Message-----
From: Ross Johnson []
Sent: Tuesday, February 25, 2003 6:16 PM
To: Craig A. Vanderborgh
Subject: Re: Trouble with mutex/cond destroy on WINCE 3.0

Craig A. Vanderborgh wrote:

>Hello All:
>I have just done a port of pthreads-win32 to our recently completed
>arm-wince-pe GNU development environment.  This is different that what
>others have been doing with pthreads-win32 in the following ways:

It looks like EBUSY is being returned by the call to 
pthread_mutex_trylock() inside of pthread_mutex_destroy(), so I'm 
wondering if there's a problem with InterlockedCompareExchange() on 

What I think may be happening is this: pthread_win32_process_attach_np() 
tries to detect if InterlockedCompareExchange() is supported by the 
system. If this check fails for any reason then: on X86 systems, some 
X86 specific assembler code is  called instead, everywhere it's needed 
throughout the library via the function pointer 
ptw32_interlocked_compare_exchange; on non-X86 systems the library 
implementation of  InterlockedCompareExchange 
(ptw32_InterlockedCompareExchange()) just returns 0, which will result 
in EBUSY being returned by trylock() [for non recursive mutexes].


What error do you get if you apply pthread_mutex_trylock() to your mutex?
Can you confirm that InterlockedCompareExchange() is supported AND being 

BTW, if it turns out that you need an ARM specific 
InterlockedCompareExchange(), then the following info may be useful:


>1. We are not using Visual C++ or EVC.  We have our own port of the GNU
>toolchain (binutils-2.13.90 & gcc-3.2).
>2. Except for a very few primitives from coredll.dll, we are not using
>the Micro$oft runtime - we are using "newlib" instead.
>The porting work that was required seemed fairly straightforward and
>affected mostly only header files in the end.  Unfortunately, the result
>is not entirely working yet.  In particular, mutex/condvar destruction
>is always returning "16" instead of "0" (EBUSY??).  Here is an example
>program that shows the problem, along with the output:
>#include <pthread.h>
>#include <errno.h>
>main(int argc, char *argv[])
>  int i, stat;
>  pthread_mutex_t mutex;
>  pthread_cond_t cond;
>  pthread_win32_process_attach_np();
>  pthread_win32_thread_attach_np();
>  stat = pthread_mutex_init(&mutex, NULL);
>  printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);
>  stat = pthread_cond_init(&cond, NULL);
>  printf("pthread_cond_init returns %d, errno %d\n", stat, errno);
>  stat = pthread_cond_destroy(&cond);
>  printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);
>  stat = pthread_mutex_destroy(&mutex);
>  printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);
>  getchar();
>The output is thus:
>thread_mutex_init returns 0, errno 0
>pthread_cond_init returns 0, errno 0
>pthread_cond_destroy returns 16, errno 0
>pthread_mutex_destroy returns 16, errno 0
>Apparently "EBUSY" is returned when there are waiters on synchronization
>objects.  Clearly that can't be the case here so there must be something
>wrong with my port.  The question is - what??  Any ideas on where to
>look or what to do would be vastly appreciated.
>craig vanderborgh
>voxware incorporated

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.

             reply	other threads:[~2003-02-26 14:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-26 14:32 Bossom, John [this message]
2003-02-26 16:06 ` Craig A. Vanderborgh
2003-02-27  2:19 ` Ross Johnson
  -- strict thread matches above, loose matches on Subject: below --
2003-02-25 17:26 Craig A. Vanderborgh
2003-02-25 23:15 ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).