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.

Unless i am mistaken a mutex operation is kernel deep, this is why it takes a "little" time for the op.