ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
My initial problem: i wrote a multithreaded application, which uses several shared resources: a vector(v) which holds several maps(which hold i.e string-kwID) (one shared res), and other two maps(2nd and 3rd shared res). Ofcourse, i am using pthread_mutex_lock to acces the resources (v[i]), but ... the time it takes for a call like pthread_mutex_lock(&my_mutex[i]) (where my_mutex is a vector of pthread_mutex_t of the same size as the vector) is unusually long, it is about 0.1->1 microseconds (on a Athlon CPU@1800MHz). The sad thing is that it happens even if i start my program with one single thread. In theory the only time taken by the call for ptread_mutex_lock would be the time needed to execute the actual call. Unfortunately measuring the time taken for the call (pthread_mutex_lock) returns the same time as above, which seems to me way to long.
The reason for which I divided the map in several partitions (the number of the elements in the vector) was to avoid having two or more threads to wait for all the map. I think that doing so I decreased the probability for a pthread_mutex_lock to wait because the resource is being used. Even like this the pthread...lock calls are eating huge amounts of time.
What would be the usuall time for such a call like pthread_mutex_lock to execute (on a single threaded app), that is without actually waiting for the resource to become available ?
If anyone could suggest me anything, it would be great.