Daniel Stenberg wrote:
>
> On Thu, 21 Mar 2002, Noel Byron wrote:

> > But if we want to reuse mutexes at all we should consider the following
> > situation: Thread A locks mutex m1 and while it is locked, Thread A locks
> > another mutex m2. This is no problem if m1 and m2 are different mutexes,
> > but if m2 and m1 are the same mutex we would have a deadlock situation.
> > Most mutex implementations are not recursive. We should keep that in mind.
>
> That's a very good point, and I haven't really put much thought on that yet.
>
> It only makes a dead-lock if the libcurl code attempts to lock two mutexes at
> the same time, as then the application might use the same native mutex for
> both of them and thus it'll hang forever.
>
> I say we should avoid (at all costs) locking two mutexes at the same time
> within libcurl (I mean within one single thread running libcurl).
>
> Right? Wouldn't that prevent this dead-lock risk?

Locking more than one mutex is allways the way to hell.

Here is an example:

Thread 1 locks mutex A and mutex B
Thread 2 locks mutex B and mutex A

> > > You then enable mutex magic in libcurl similar to this:
> > >
> > > struct curl_mutex1 moootexx=
> > > {CURL_MUTEX_ONE, NULL, my_unlock, my_lock};
> > >
> > > curl_easy_setopt(easy, CURLOPT_MUTEX, &moootexx);
> >
> > Ah, now it becomes clearer. I had a totally diffent view.
>
> I figured that. That's also why I like to talk around actual code examples
> and prototypes. It makes it less abstract.

I like the idea with general pointers:

struct curl_murex_data cumuda =
{ my_mutex_create,
  my_mutex_destroy,
  pthread_mutex_lock,
  pthread_mutex_unlock
};

(posix threads assumed...)

Bye

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126