lets start it using CUDA 

On Mon, Dec 10, 2012 at 9:48 PM, Mark Reynolds <mareynol@redhat.com> wrote:


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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

--
Mark Reynolds
Red Hat, Inc
mreynolds@redhat.com