Re: [Firebird-devel] Vulcan vector,vcl, SIVector, SVector question

[Alex P. <pes...@ma...>]

On Monday 23 July 2007 23:10, Dmitry Yemanov wrote:
> This is the original Vulcan's approach to multi-threading and I followed
> it when committing synchronization bugfixes. It's ugly and I believe it
> was considered a temporary solution, but nobody cared to cleanup this
> stuff yet. But the real problem is that SIVector is not really
> thread-safe. Alex should provide you with more information, if you wish.

Looks like it's time to have dedicated web-page concerning SIVector :)

SIVector uses=20

   class Element
        {
=2E..
            Element& operator =3D (Type newValue)
                {
                parent->set(index, newValue);
                return *this;
                }

=2E..

to implement=20

   Element operator[](size_type n)
        {
        return Element(this,n);
        }

All this is to call function:
=A0 =A0 Type Element::set(size_type n, Type newValue)
=A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 Sync sync (&syncObject, "SIVector::set");
=A0 =A0 =A0 =A0 sync.lock(Shared);

=A0 =A0 =A0 =A0 if( n >=3D length )
=A0 =A0 =A0 =A0 =A0 =A0 throw OSRIBugcheck("vector index error");

=A0 =A0 =A0 =A0 buffer[n] =3D newValue;

=A0 =A0 =A0 =A0 return newValue;
=A0 =A0 =A0 =A0 }

This greatly protects vector from assigning newValue to location out of=20
buffer, avoiding BO. It's also great if another thread expands vector and=20
needs to allocate another buffer of memory for it's contents. So far so goo=
d.=20
But - shared lock is taken AFTER size_type n was calculated somewhere in th=
e=20
code outside of this class. Imagine:
=A0 =A0 thr1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0thr2
=A0 =A0 need replace element 4 in=20
=A0 =A0 vector with length 10, calls:
=A0 =A0 =A0 vec[4] =3D ....
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 removes element 2 from that vector
=A0 =A0 takes shared lock, but replaces
=A0 =A0 WRONG element in the vector

and all this races without any error diagnostics - except AV later when=20
something like wrong pointer, previously stored in vec[4], but moved=20
by 'thr2' into vec[3] is used :-))

When I asked Jim about it (2 years ago approx.) he answered that this can=20
happen, but SIVector should not be used in that way. I wonder, who remember=
s=20
this warning well now, and what for do we need such protection which protec=
ts=20
something only from deleting last element in the vector or adding in the ve=
ry =20
end? (Ouuhh, element also may be inserted before last one...)