Re: [Evolution-hackers] camel summary locking
- From: Jeffrey Stedfast <fejj novell com>
- To: Lee Revell <rlrevell joe-job com>
- Cc: Evolution Hackers <evolution-hackers lists ximian com>
- Subject: Re: [Evolution-hackers] camel summary locking
- Date: Sun, 17 Apr 2005 22:29:37 -0400
pretty sure the code is correct
Jeff
On Sun, 2005-04-17 at 20:33 -0400, Lee Revell wrote:
> This comment (camel/camel-private.h:124) does not agree with the code:
>
> GMutex *ref_lock; /* for reffing/unreffing messageinfo's ALWAYS obtain before summary_lock */
>
> >From camel/camel-folder-summary.c:
>
> CamelMessageInfo *
> camel_folder_summary_index(CamelFolderSummary *s, int i)
> {
> CamelMessageInfo *info = NULL;
>
> CAMEL_SUMMARY_LOCK(s, summary_lock);
> CAMEL_SUMMARY_LOCK(s, ref_lock);
>
> if (i<s->messages->len)
> info = g_ptr_array_index(s->messages, i);
>
> if (info)
> info->refcount++;
>
> CAMEL_SUMMARY_UNLOCK(s, ref_lock);
> CAMEL_SUMMARY_UNLOCK(s, summary_lock);
>
> return info;
> }
>
> Which is correct, the comment or the code? If I switch the locking
> order around it works fine.
>
> My profiling indicates there's some lock contention going on in this
> function. It's hard to tell whether reversing the locking order helps.
>
> Lee
>
> _______________________________________________
> evolution-hackers maillist - evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]