* pthread_cond_timedwait
@ 1999-09-09 8:51 Mikael.Ambrus
1999-09-09 9:21 ` pthread_cond_timedwait Scott Lightner
1999-09-09 14:07 ` [pthread-win32] pthread_cond_timedwait Tristan Savatier
0 siblings, 2 replies; 3+ messages in thread
From: Mikael.Ambrus @ 1999-09-09 8:51 UTC (permalink / raw)
To: pthreads-win32
[Ambrus Mikael] Dear pthreads colleagues,
I'm writing a program that uses pthread_cond_timedwait. In the book
that I'm using (Pthreads Programming by Nicols, Buttlar & Proulux Farell )
it says that this function should suspend the thread until some other thread
calls pthread_cond_signal, pthread_cond_broadcast OR the system timer is
greater than or equal to the third argument (abstime).
Since clock_gettime is not implemented and I cant find some other
function that tells me the system time, I've tried to implement my own
version of clock_gettime by using the ansi function clock(). This function
returns the number of ticks that has elapsed since the program was started.
But it seams that this is not the same absolute time that
pthread_cond_timedwait requires since the thread won't awaken.
Is there another way to acquire the relevant system time?
Another thing that has bothered me is that I recently downloaded the
latest snip of phtreads and now my read/write locks won't work. Since the
precompiled lib isn't recognised by the linker (neither with gcc v20.1 nor
MSVC 6.0) for some reason, I built the libs using the buildlib.bat provided.
Here's a snip of the code that fails:
int pthread_rdwr_wunlock_np (
pthread_rdwr_t *rdwrp
){
assert( pthread_mutex_lock(&(rdwrp->mutex)) == 0 );
if (rdwrp->writers_writing == 0) {
assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 );
return(-1);
}else{
rdwrp->writers_writing = 0;
assert(pthread_cond_broadcast(&(rdwrp->lock_free)) == 0);
};
assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 );
return(0);
};
pthread_cond_broadcast returns EINVAL. Does anyone recognise this
problem?
Wkr
Michael Ambrus
Siemens Elema
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: pthread_cond_timedwait 1999-09-09 8:51 pthread_cond_timedwait Mikael.Ambrus @ 1999-09-09 9:21 ` Scott Lightner 1999-09-09 14:07 ` [pthread-win32] pthread_cond_timedwait Tristan Savatier 1 sibling, 0 replies; 3+ messages in thread From: Scott Lightner @ 1999-09-09 9:21 UTC (permalink / raw) To: pthreads-win32 _ftime() will give you the current time with milliseconds. I believe struct timespec is in nanoseconds so you will lose some precision. Scott ----- Original Message ----- From: <Mikael.Ambrus@elema.siemens.se> To: <pthreads-win32@sourceware.cygnus.com> Sent: Thursday, September 09, 1999 11:47 AM Subject: pthread_cond_timedwait > [Ambrus Mikael] Dear pthreads colleagues, > > I'm writing a program that uses pthread_cond_timedwait. In the book > that I'm using (Pthreads Programming by Nicols, Buttlar & Proulux Farell ) > it says that this function should suspend the thread until some other thread > calls pthread_cond_signal, pthread_cond_broadcast OR the system timer is > greater than or equal to the third argument (abstime). > > Since clock_gettime is not implemented and I cant find some other > function that tells me the system time, I've tried to implement my own > version of clock_gettime by using the ansi function clock(). This function > returns the number of ticks that has elapsed since the program was started. > > But it seams that this is not the same absolute time that > pthread_cond_timedwait requires since the thread won't awaken. > > Is there another way to acquire the relevant system time? > > Another thing that has bothered me is that I recently downloaded the > latest snip of phtreads and now my read/write locks won't work. Since the > precompiled lib isn't recognised by the linker (neither with gcc v20.1 nor > MSVC 6.0) for some reason, I built the libs using the buildlib.bat provided. > Here's a snip of the code that fails: > > int pthread_rdwr_wunlock_np ( > pthread_rdwr_t *rdwrp > ){ > assert( pthread_mutex_lock(&(rdwrp->mutex)) == 0 ); > if (rdwrp->writers_writing == 0) { > assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 ); > return(-1); > }else{ > rdwrp->writers_writing = 0; > assert(pthread_cond_broadcast(&(rdwrp->lock_free)) == 0); > > }; > > assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 ); > return(0); > }; > > pthread_cond_broadcast returns EINVAL. Does anyone recognise this > problem? > > Wkr > Michael Ambrus > Siemens Elema > > > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pthread-win32] pthread_cond_timedwait 1999-09-09 8:51 pthread_cond_timedwait Mikael.Ambrus 1999-09-09 9:21 ` pthread_cond_timedwait Scott Lightner @ 1999-09-09 14:07 ` Tristan Savatier 1 sibling, 0 replies; 3+ messages in thread From: Tristan Savatier @ 1999-09-09 14:07 UTC (permalink / raw) To: Mikael.Ambrus; +Cc: pthreads-win32 use _ftime(). For systems where _ftime() is not available, you can use GetSystemTime and convert it to a FILETIME with SystemTimeToFileTime. Note: _ftime is NOT available on WinCE, so I had to do that for the WinCE port of posix_thread... The problem is that the posix standard uses system time defined as number of microseconds since jan 1, 1970, whereas the windows FILETIME is defined as the number of 100 nanosecs since jan 1, 1601! I have written two small routines to convert between those two: #ifndef USE_FTIME /* time between jan 1, 1601 and jan 1, 1970 in units of 100 nanoseconds */ #define TIMESPEC_TO_FILETIME_OFFSET (((LONGLONG)27111902 << 32) + (LONGLONG)3577643008) static void timespec_to_filetime(const struct timespec *ts, FILETIME *ft) /* * ------------------------------------------------------------------- * converts struct timespec * where the time is expressed in seconds and nanoseconds from Jan 1, 1970. * into FILETIME (as set by GetSystemTimeAsFileTime), where the time is * expressed in 100 nanoseconds from Jan 1, 1601, * ------------------------------------------------------------------- */ { *(LONGLONG *)ft = ts->tv_sec * 10000000 + (ts->tv_nsec + 50) / 100 + TIMESPEC_TO_FILETIME_OFFSET; } static void filetime_to_timespec(const FILETIME *ft, struct timespec *ts) /* * ------------------------------------------------------------------- * converts FILETIME (as set by GetSystemTimeAsFileTime), where the time is * expressed in 100 nanoseconds from Jan 1, 1601, * into struct timespec * where the time is expressed in seconds and nanoseconds from Jan 1, 1970. * ------------------------------------------------------------------- */ { ts->tv_sec = (int)((*(LONGLONG *)ft - TIMESPEC_TO_FILETIME_OFFSET) / 10000000); ts->tv_nsec = (int)((*(LONGLONG *)ft - TIMESPEC_TO_FILETIME_OFFSET - ((LONGLONG)ts->tv_sec * (LONGLONG)10000000)) * 100); } #endif /* not USE_FTIME */ --------------------------- To get the current system time: _ftime(&currSysTime); or { FILETIME ft; SYSTEMTIME st; GetSystemTime(&st); SystemTimeToFileTime(&st, &ft); /* GetSystemTimeAsFileTime(&ft); would be faster, but it does not exist on WinCE */ filetime_to_timespec(&ft, &currSysTime); } -------------------------- I hope this helps! -t Mikael.Ambrus@elema.siemens.se wrote: > > [Ambrus Mikael] Dear pthreads colleagues, > > I'm writing a program that uses pthread_cond_timedwait. In the book > that I'm using (Pthreads Programming by Nicols, Buttlar & Proulux Farell ) > it says that this function should suspend the thread until some other thread > calls pthread_cond_signal, pthread_cond_broadcast OR the system timer is > greater than or equal to the third argument (abstime). > > Since clock_gettime is not implemented and I cant find some other > function that tells me the system time, I've tried to implement my own > version of clock_gettime by using the ansi function clock(). This function > returns the number of ticks that has elapsed since the program was started. > > But it seams that this is not the same absolute time that > pthread_cond_timedwait requires since the thread won't awaken. > > Is there another way to acquire the relevant system time? > > Another thing that has bothered me is that I recently downloaded the > latest snip of phtreads and now my read/write locks won't work. Since the > precompiled lib isn't recognised by the linker (neither with gcc v20.1 nor > MSVC 6.0) for some reason, I built the libs using the buildlib.bat provided. > Here's a snip of the code that fails: > > int pthread_rdwr_wunlock_np ( > pthread_rdwr_t *rdwrp > ){ > assert( pthread_mutex_lock(&(rdwrp->mutex)) == 0 ); > if (rdwrp->writers_writing == 0) { > assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 ); > return(-1); > }else{ > rdwrp->writers_writing = 0; > assert(pthread_cond_broadcast(&(rdwrp->lock_free)) == 0); > > }; > > assert( pthread_mutex_unlock(&(rdwrp->mutex)) == 0 ); > return(0); > }; > > pthread_cond_broadcast returns EINVAL. Does anyone recognise this > problem? > > Wkr > Michael Ambrus > Siemens Elema > > -- Regards, -- Tristan Savatier (President, MpegTV LLC) MpegTV: http://www.mpegtv.com - Xaudio: http://www.xaudio.com MPEG.ORG: http://www.mpeg.org - Tel: (415) 864 6466 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1999-09-09 14:07 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-09 8:51 pthread_cond_timedwait Mikael.Ambrus 1999-09-09 9:21 ` pthread_cond_timedwait Scott Lightner 1999-09-09 14:07 ` [pthread-win32] pthread_cond_timedwait Tristan Savatier
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).