Re: To multi thread or NOT to multi thread?

2005-09-28 Thread Lefteris Tsintjelis
John McCaskey wrote: I wasnt quite sure about the safety of the error output that occured later on, but it is true for sure in the case of no errors occuring releasing sooner is safe. Good optimization. I have no problems here using it like that, or any errors or core dumps or connectivity pro

Re: To multi thread or NOT to multi thread?

2005-09-28 Thread John McCaskey
Hi, On 9/28/05, Lefteris Tsintjelis <[EMAIL PROTECTED]> wrote: > > John McCaskey wrote: > > Hello again, > > > > I modified your threading code to use a thread pool. Here are my > results: > > Hello, > > I modified the thread pool a bit to get rid of that lock ASAP. It is safe > to get rid of that

Re: To multi thread or NOT to multi thread?

2005-09-28 Thread Lefteris Tsintjelis
John McCaskey wrote: Hello again, I modified your threading code to use a thread pool. Here are my results: Hello, I modified the thread pool a bit to get rid of that lock ASAP. It is safe to get rid of that lock right after mysql_store_results. http://dev.mysql.com/doc/mysql/en/threaded-cli

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread John McCaskey
Hello again, I modified your threading code to use a thread pool. Here are my results: pooled-threading.c: [EMAIL PROTECTED]:~$ gcc -lmysqlclient_r -lpthread pooled-threading.c [EMAIL PROTECTED]:~$ time ./a.out Thread Safe ON real 0m0.068s user 0m0.041s sys 0m0.097s [EMAIL PROTECTED]:~$ time ./a

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread Lefteris Tsintjelis
Pooly wrote: 2005/9/27, Lefteris Tsintjelis <[EMAIL PROTECTED]>: Hi, What makes me wonder is that the same test, with the code stripped down, to my surprise, is significantly faster that the multi threaded one, no matter how many times I run the tests. I am including the code for both test

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread Pooly
2005/9/27, Lefteris Tsintjelis <[EMAIL PROTECTED]>: > Hi, > > What makes me wonder is that the same test, with the code > stripped down, to my surprise, is significantly faster that the > multi threaded one, no matter how many times I run the tests. I am > including the code for both tests I r

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread John McCaskey
Hi again, On 9/27/05, Lefteris Tsintjelis <[EMAIL PROTECTED]> wrote: > > John McCaskey wrote: > > Hi, > > > > I think I can shed a bit of light on the topic. There are several > reasons > > why your multithreaded code is not a good example and would be slower. > > > > 1) locking/unlocking mutexes

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread Lefteris Tsintjelis
John McCaskey wrote: Hi, I think I can shed a bit of light on the topic. There are several reasons why your multithreaded code is not a good example and would be slower. 1) locking/unlocking mutexes of course does add *some* overhead *lots* would probably be a better choice here! :) 2) you

Re: To multi thread or NOT to multi thread?

2005-09-27 Thread John McCaskey
Hi, I think I can shed a bit of light on the topic. There are several reasons why your multithreaded code is not a good example and would be slower. 1) locking/unlocking mutexes of course does add *some* overhead 2) you have a single database connection and are passing it around between threads t

To multi thread or NOT to multi thread?

2005-09-27 Thread Lefteris Tsintjelis
Hi, What makes me wonder is that the same test, with the code stripped down, to my surprise, is significantly faster that the multi threaded one, no matter how many times I run the tests. I am including the code for both tests I run. Since I couldn't find a good example of mutex locking t