Hi Gilad, first, thanks for your efforts to help. I'll try to give a brief explanation of what I'm trying to do. Well, I'll not use the word "timer, but "timeout". In any case, I'll be glad to hear from you if, still, timers were not the correct wording here. I'm working as a freelancer for a company involved in cellular communications and I was asked to write a kind of connections manager application. My application has to be able to manage concurrent (parallel) connections to some multicell systems, which may be roughly defined as celllular centrals. Those multicell systems exchange messages with my application for some tasks to be done by my application. In addition, there is a kind of software (let's call it client software) that knows to communicate with those multicell systems through my application. So, basically there may be such client software used on various other computers at the same time and should be connected to my application concurrently. And yet also, my application has to connect to an ftp server to upload some kind of files. As I said, all connections have to be concurrent and not blocking others. I chose for this the multithread approach, where each connection is a thread. Yeah, I know, many people would advise using non-blocking sockets here, but this is my weak part and I was in ahurry, so I decided to postpone this learning curve to a later occasion and chose multithreads. Why timeouts? For example, a timeout to block the ftp thread, which after it there is a reconnection to ftp server for upload. In case there is no connection to any of the multicell systems, a timeout to wait and then retry connection again. In case of connection with what I called client software, I have a very simple ling-pong protocol to make sure there is connection between this software and my application and again after my application sends a "ping" it should wait for an adjustable time (by default 10 seconds) for the pong reply. So, as you see, various timeouts and all of them should be able to proceed cuncurrently and unaffected by any other one. Unfortunately, what I see in my case is that the most recent timeout "takes the lead" on all other blocked threads at that time and affects their timeouts. So for example, if the recent timeout was the one for the ftp and it is for a couple of hours, all the other threads that were blocked for their timeouts, remain blocked all along the last one. And here lies my problem. If you say that the system has a single timer than that may well be the problem, and each thread needs to have it's own independent timer (timer again?). So, I do think there is a problem with my strategy. If you say thet pthread_cond_timedwait blocks the whole system, this is bad. I intended to block a single thread, and that's what I thought it should do. Concerning clock_gettime function, there is an alternative of CLOCK_THREAD_CPUTIME_ID as it's first argument. I did not try it yet, but may be this could lead to a better solution. Ah, very lengthy message, still clear I hope. I'll be glad to continue and receive assistance. Thanks Gilad, Rafi.
-----Original Message----- From: Gilad Ben-Yossef [mailto:[EMAIL PROTECTED] Sent: Saturday, November 10, 2007 10:23 AM To: Rafi Cohen Cc: linux-il@cs.huji.ac.il Subject: Re: concurrent timers on linux Rafi Cohen wrote: > My application is a multithread one, for which each thread has it's > own > timer and tasks upon timeout. Each timer may be different (varies from > 10 seconds in one case to 24 hours in another). > Each timer should also be independent and the threads should run > concurrently withou actually affecting other threads and timers. POSIX only supply a single timer counting in real time for each process. Multiple timers are either created by the programmer based on this single timer using a timer heap or the same done by the threading library pthread create_timer. > It seems that there still is some effect of some timers to others and > I > don't achieve the goal of total independency of timers. There is just one timer. > Here is the strategy I decided to use, by the way, my code is in C: > Each thread uses in a loop the function pthread_cond_timedwait. Part > of them may exit either upon signal or time out and part of them > actually waits until timeout. This is not a timer. It's a blocking system call with a timeout. > The problem I think I see is the timer adjustment prior to using > pthread_cond_timedwait. What timer? you're using a blocking system call with a timeout. > I sould also note that each thread has it's own and unique mutex and > condition variables for this function. > The time adjustment is done by calling clock_gettime with CLOCK_REALTIME > as it's first parameter. > This is called before each use of pthread_cond_timedwait and immediately > after call to clock_gettime I add the timeout seconds to the tv_sec > field of the timespec structure. > Now, to my questions: > 1. Does this strategy seem correct, if not please give other ideas. That's how it is supposed to be used > 2. Specifically, is the function clock_gettime the correct one to use, > should it's first parameter be the one I use and should it be called > indeed before each pthread_cond_timedwait within the loop, or only once > before the loop. Anyway, clock_gettime is the correct one. CLOCK_REALTIME is correct and you need to call it only once before entering the loop. The man page has an excellent code example code: http://linux.die.net/man/3/pthread_cond_timedwait Search for "Timed Condition Wait" > I'll be glad to have detailed ideas, in case you think I'm wrong here. I don't think I understand what you're trying to achieve exactly. > 3. Shachar (Shemes), you pointed me once to the libevent library as an > alternative. > I looked into this library and was very willing to use it. However, I > understood from it's documentation that it is not threadsafe. > Therefore, it seems not to be the right idea to use it for concurrent > timers. Timers? "You keep saying that word. I don't think you know what it means..." :-) > Am I wrong here? I'll be glad to stand corrected and use such option > instead of the strategy I mentioned above. > Any assistance will be most appreciated. A description of what you are trying to do will do wonders here, I think. And why threads, anyway? > Note: I raise programming issues here from time to time and get good > answers most of the time. However, probably there are more linux users > than programmers here. So, if you think there should be a better forum > or mailing list to raise such questions, then please let me know. > I do think however, that there are here really knowledgeable people that > may and I believe will help the best they can. This happens to be the most technical Linux oriented mailing list in Israel. gilad -- Gilad Ben-Yossef <[EMAIL PROTECTED]> Codefidence. A name you can trust(tm) Web: http://codefidence.com | SIP: [EMAIL PROTECTED] IL: +972.3.7515563 ext. 201 | Fax: +972.3.7515503 US: +1.212.2026643 ext. 201 | Cel: +972.52.8260388 "There once was a virtualization coder, Whose patches kept getting older, Each time upstream would drop, His documentation would slightly rot, SO APPLY MY F*$KING PATCHES OR I'LL KEEP WRITING LIMERICKS." -- Rusty Russel -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.27/1121 - Release Date: 11/9/2007 7:29 PM ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
