Re: [Evolution-hackers] camel summary locking



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]