Sponsored Content
Operating Systems Linux Strange problem with gettimeoftheday function Post 302184252 by xyz123456 on Friday 11th of April 2008 03:40:27 AM
Old 04-11-2008
Bug Strange problem with gettimeoftheday function

Hi all,
I am using pthread_cond_timedwait function in my program, to generate the time period of waiting i use gettimeoftheday function.

When i run the code after compiling i get a core dump error. However my program runs perfectly if i give a printf statement before the gettimeoftheday function. Smilie Can anyone explain this problem . I have pasted the part of the code for your reference:

pthread_mutex_lock(&lock);
//printf("After core dump \n");
gettimeofday(&tp, NULL);
ts.tv_sec = tp.tv_sec;
ts.tv_nsec = tp.tv_usec * 1000;
ts.tv_sec += WAIT_TIME_SECONDS;
pthread_cond_timedwait(&write, &lock, &ts);
pthread_mutex_unlock(&lock);

Thanks in advance,
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Strange problem.Please Help !

I¡¯m a network operator, mine is an IBM PC server 320, operating system SCO unix 3.2v4.2, triton 3.1 of Baan. Recently, my server went dead every a few hours, no sign & signal shows malfunction suddenly. It looks like a sudden power failure, but the indicator of main power supply is on. Normal... (1 Reply)
Discussion started by: lyhsm
1 Replies

2. Shell Programming and Scripting

Strange problem

I am using SunOS 5.9 and I don't know why all my commands are getting executed as if an extra 'enter' has been pressed. What could be the reason and how to correct it? Please help. Asty (2 Replies)
Discussion started by: Asty
2 Replies

3. UNIX for Dummies Questions & Answers

Converting gettimeoftheday output to string

Hi .. is there a way i can retrieve the output of gettimeoftheday in a string (1 Reply)
Discussion started by: p_aishwarya
1 Replies

4. Shell Programming and Scripting

Very strange things happened in the shell function

Here is the script: #!/bin/bash #set -xv RAWDATAFILE="temp1" GOODDATAFILE="temp2" FindSOS() { local NUM=0 #return value for the id of SOS local cnt=1 if grep "EOS" $1 then sed -e 's/.*<CobDate>//' -e 's/<\/.*//' <$1 > ${RAWDATAFILE} sed -n -e '/EOS/,/SOS/ s/*/&/p' <${RAWDATAFILE}... (2 Replies)
Discussion started by: tpltp
2 Replies

5. Shell Programming and Scripting

Strange problem.

Well, my script started off to do what i wanted. Now, i think its not recognizing the pattern so its not moving anything. What i have to do is execute my script command for the move to take effect. So i did that and yayy it worked. Strange thing is that my DESTDIR was empty to begin with.... (2 Replies)
Discussion started by: oxoxo
2 Replies

6. UNIX and Linux Applications

strange behavior of PSQL user defined function

Segregated the problematic portion, and showing for your view here., 1. Following is the function definition, create or replace function new_del(id integer) returns void as $$ begin raise info 'dollar :%',$1; delete from testing where id=$1; end ; $$ language 'plpgsql'; ... (1 Reply)
Discussion started by: thegeek
1 Replies

7. Shell Programming and Scripting

Strange Problem

Hi All, I am encountering an unexpected problem while running my process, using daemon placed in /etc/init.d/. I have a process that is opening shared library using dlopen. When I run my process on the command line, it is able to open the library. But when I used daemon to run my process, I... (0 Replies)
Discussion started by: qwerty-1
0 Replies

8. Shell Programming and Scripting

strange problem

hello all, i am having problem in accessing a directory.I dont think its a permission issue.can anyone help me out. I am using korn sell code: $ ls -ltr sc* lrwxrwxrwx 1 essbase essbase 21 Oct 8 2010 sc_ssp -> /work/nfs/nas2/sc_ssp $ cd sc_ssp ksh: sc_ssp: not found $ (6 Replies)
Discussion started by: manid
6 Replies

9. Shell Programming and Scripting

Strange function call in the shell script parse_prog_args $@

I am converting shell script to Perl. In shell I have a code parse_prog_args() { if then while do case $1 in -P* | -p* ) export PROCESS_DATE=$2 export MM=`echo $2 | cut -c5-6` export DD=`echo $2 | cut -c7-8` export YY=`echo $2 | cut -c3-4` export... (4 Replies)
Discussion started by: digioleg54
4 Replies

10. Shell Programming and Scripting

Strange third argument in shell function

In one of my shell function I found the following set_default_values () { prog=$1 PROC_DT=$2 RESET_ALL="${3-N}" #echo "Processing date as passed = , Program name = " ...... I understand the first and second arguments, but don't understand... (1 Reply)
Discussion started by: digioleg54
1 Replies
PTHREAD_COND(3) 					     Library Functions Manual						   PTHREAD_COND(3)

NAME
pthread_cond_init, pthread_cond_destroy, pthread_cond_signal, pthread_cond_broadcast, pthread_cond_wait, pthread_cond_timedwait - opera- tions on conditions SYNOPSIS
#include <pthread.h> pthread_cond_t cond = PTHREAD_COND_INITIALIZER; int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *cond_attr); int pthread_cond_signal(pthread_cond_t *cond); int pthread_cond_broadcast(pthread_cond_t *cond); int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex); int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime); int pthread_cond_destroy(pthread_cond_t *cond); DESCRIPTION
A condition (short for ``condition variable'') is a synchronization device that allows threads to suspend execution and relinquish the pro- cessors until some predicate on shared data is satisfied. The basic operations on conditions are: signal the condition (when the predicate becomes true), and wait for the condition, suspending the thread execution until another thread signals the condition. A condition variable must always be associated with a mutex, to avoid the race condition where a thread prepares to wait on a condition variable and another thread signals the condition just before the first thread actually waits on it. pthread_cond_init initializes the condition variable cond, using the condition attributes specified in cond_attr, or default attributes if cond_attr is NULL. The LinuxThreads implementation supports no attributes for conditions, hence the cond_attr parameter is actually ignored. Variables of type pthread_cond_t can also be initialized statically, using the constant PTHREAD_COND_INITIALIZER. pthread_cond_signal restarts one of the threads that are waiting on the condition variable cond. If no threads are waiting on cond, nothing happens. If several threads are waiting on cond, exactly one is restarted, but it is not specified which. pthread_cond_broadcast restarts all the threads that are waiting on the condition variable cond. Nothing happens if no threads are waiting on cond. pthread_cond_wait atomically unlocks the mutex (as per pthread_unlock_mutex) and waits for the condition variable cond to be signaled. The thread execution is suspended and does not consume any CPU time until the condition variable is signaled. The mutex must be locked by the calling thread on entrance to pthread_cond_wait. Before returning to the calling thread, pthread_cond_wait re-acquires mutex (as per pthread_lock_mutex). Unlocking the mutex and suspending on the condition variable is done atomically. Thus, if all threads always acquire the mutex before sig- naling the condition, this guarantees that the condition cannot be signaled (and thus ignored) between the time a thread locks the mutex and the time it waits on the condition variable. pthread_cond_timedwait atomically unlocks mutex and waits on cond, as pthread_cond_wait does, but it also bounds the duration of the wait. If cond has not been signaled within the amount of time specified by abstime, the mutex mutex is re-acquired and pthread_cond_timedwait returns the error ETIMEDOUT. The abstime parameter specifies an absolute time, with the same origin as time(2) and gettimeofday(2): an abstime of 0 corresponds to 00:00:00 GMT, January 1, 1970. pthread_cond_destroy destroys a condition variable, freeing the resources it might hold. No threads must be waiting on the condition vari- able on entrance to pthread_cond_destroy. In the LinuxThreads implementation, no resources are associated with condition variables, thus pthread_cond_destroy actually does nothing except checking that the condition has no waiting threads. CANCELLATION
pthread_cond_wait and pthread_cond_timedwait are cancellation points. If a thread is cancelled while suspended in one of these functions, the thread immediately resumes execution, then locks again the mutex argument to pthread_cond_wait and pthread_cond_timedwait, and finally executes the cancellation. Consequently, cleanup handlers are assured that mutex is locked when they are called. ASYNC-SIGNAL SAFETY The condition functions are not async-signal safe, and should not be called from a signal handler. In particular, calling pthread_cond_sig- nal or pthread_cond_broadcast from a signal handler may deadlock the calling thread. RETURN VALUE
All condition variable functions return 0 on success and a non-zero error code on error. ERRORS
pthread_cond_init, pthread_cond_signal, pthread_cond_broadcast, and pthread_cond_wait never return an error code. The pthread_cond_timedwait function returns the following error codes on error: ETIMEDOUT the condition variable was not signaled until the timeout specified by abstime EINTR pthread_cond_timedwait was interrupted by a signal The pthread_cond_destroy function returns the following error code on error: EBUSY some threads are currently waiting on cond. AUTHOR
Xavier Leroy <Xavier.Leroy@inria.fr> SEE ALSO
pthread_condattr_init(3), pthread_mutex_lock(3), pthread_mutex_unlock(3), gettimeofday(2), nanosleep(2). EXAMPLE
Consider two shared variables x and y, protected by the mutex mut, and a condition variable cond that is to be signaled whenever x becomes greater than y. int x,y; pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; Waiting until x is greater than y is performed as follows: pthread_mutex_lock(&mut); while (x <= y) { pthread_cond_wait(&cond, &mut); } /* operate on x and y */ pthread_mutex_unlock(&mut); Modifications on x and y that may cause x to become greater than y should signal the condition if needed: pthread_mutex_lock(&mut); /* modify x and y */ if (x > y) pthread_cond_broadcast(&cond); pthread_mutex_unlock(&mut); If it can be proved that at most one waiting thread needs to be waken up (for instance, if there are only two threads communicating through x and y), pthread_cond_signal can be used as a slightly more efficient alternative to pthread_cond_broadcast. In doubt, use pthread_cond_broadcast. To wait for x to becomes greater than y with a timeout of 5 seconds, do: struct timeval now; struct timespec timeout; int retcode; pthread_mutex_lock(&mut); gettimeofday(&now); timeout.tv_sec = now.tv_sec + 5; timeout.tv_nsec = now.tv_usec * 1000; retcode = 0; while (x <= y && retcode != ETIMEDOUT) { retcode = pthread_cond_timedwait(&cond, &mut, &timeout); } if (retcode == ETIMEDOUT) { /* timeout occurred */ } else { /* operate on x and y */ } pthread_mutex_unlock(&mut); LinuxThreads PTHREAD_COND(3)
All times are GMT -4. The time now is 02:37 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy