Marcus Crafter wrote:
> On Tue, Mar 05, 2002 at 08:55:04AM -0500, Berin Loritsch wrote:
>
>>Gregory Steuck wrote:
>>
>>>>>>>>"Peter" == Peter Royal <[EMAIL PROTECTED]> writes:
>>>>>>>>
>>>>>>>>
>>>As far as I can tell there is a bug in method add in rev 1.2-1.4 of
>>>VariableSizeBuffer. The way it handles array growth is not right when
>>>(m_tail < m_head). Buffer ends up containing a bunch of nulls that
>>>were never put there. I will try to produce a test case and a fix
>>>tomorrow unless somebody beats me to it...
>>>
>
> It definitely doesn't look threadsafe:
The buffer classes themselves are not ThreadSafe. It was never the
intention for them to be that way. It is the Queue that must be
ThreadSafe. The Queue is supposed to synchronize on the buffer for
each add and remove operation.
> from VariableSizeBuffer.add():
>
> if( size() + 1 >= m_buffer.length )
> {
> Object[] tmp = new Object[ ( (m_buffer.length - 1) * 2) + 1
> ];
>
> for ( int i = 0; i < m_buffer.length; i++ )
> {
> tmp[i] = m_buffer[i];
> m_buffer[i] = null;
> }
>
> m_buffer = tmp;
> }
>
> If 2 threads add objects at the same time causing the internal
> buffer to grow, it could cause the grow code to happen in each thread.
Entirely possible, but that means that the Queue needs to manage the
synchronization on the buffer.
> What you are probably seeing is one thread set m_buffer[i] to null a
> few iterations ahead of the other thread, with it copying those nulls
> across into the new Object array which replaces m_buffer.
>
> Perhaps this growth code should be considered a critical area if
> the class should be threadsafe ?
The buffer is not intended to be ThreadSafe. Synchronization should be
in the Queue.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
