On 03/18/2014 04:11 PM, Dimitry Sibiryakov wrote: > 18.03.2014 12:47, Alex wrote: >> IAttachment* userHandle points to class YAttachment, containing (among >> others) reference counter and reference pointer to IAttachment next. >> Let's take into an account that on successful detach next is nullified, >> and if other references are present (i.e. YAttachment is not destroyed >> due to reference counter > 0) any attempt to use it should raise >> 'invalid handle' error. >> >> Let N (where N > 1) threads to work with this attachment (i.e. reference >> counter is N). Thread T1 wants to execute statement - it calls >> YAttachment::execute, which checks for non-null next pointer and (at >> this time T1 is swapped out, T2 calls detach, next is nullified ...) > At first, is new API reenterable? I.e. can, say, YAttachment.execute() be > called from > second thread while the same call from first thread is not finished? Old API > wasn't > reenterable that's why it required mutex to be hold during whole call time. > The same is > about network protocol: you cannot send new request before have got response > for previous.
yvalve is reenterable, all the rest depends upon providers we must start with something >> invokes next function: next->execute(...). And gets segfault. Absolutely >> without mutex this is not solvable, but we want to keep it locked for as >> small time as possible. Therefore under locked mutex we copy next to >> local variable, addRef() to it, unlock mutex (you see it's locked for a >> very small timeslice) and later work with this variable. In the sample >> above we will invoke next->execute() and get 'invalid handle' message >> from next provider. IMHO it's better than segfault. > But it is build on fact that next is nullified on detach. If remove this > nullification > and always get 'invalid handle' from the next provider, there will be no need > for mutex > and extra wrappers at all. What is wrong to let next IAttachment to live a > bit longer? > The main reason is an ability to delete provider's object better sooner than later. - yvalve object is tiny and consumes very low resources - provider's object may be relatively big - and as a last '+' we can unload provider after nullifying next pointer ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
