On 12/10/2012 10:57 AM, Ludwig Krispenz wrote:
And I think be_addsuffix is not safe.
If two threads try to add a suffix, both can get the same current
count, the both set the new suffix
be->be_suffix[count]= slapi_sdn_dup(suffix);
and then both increment count. the increment is atomic, but the
assignment could be done to the wrong index.
Hi Ludwig,
Nice catch, patch is revised to use the suffix lock when adding a new
suffix.
As for the first issue you mentioned, I do not see this being a
problem. We would of requested a be search prior to a new suffix being
created. Once the suffix is fully added, then we increment the count.
So I don't see any issue with this.
Mark
Ludwig
On 12/10/2012 04:49 PM, Ludwig Krispenz wrote:
Hi Mark,
in the locked version the list of suffixes cannot be changed while
you loop over them. In your version you get the suffix count and the
do a for loop i=0..count on it. Although suffixes don't get deleted
from the array there couls be cases where one is added from the time
you get the count to whwn you execute the loop. Could this be a
problem ?
Ludwig
On 12/10/2012 04:29 PM, Mark Reynolds wrote:
Here is the lock-free version....
https://fedorahosted.org/389/ticket/509
https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.patch
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
Mark Reynolds
Red Hat, Inc
mreynolds@xxxxxxxxxx
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
