Partition problem

[Leon Pollak]

Thank you, Tim.
The issue you write is clear for me.
But reading the docs, I was sure that partition is thread safe. Also, looking 
into the code shows a lot of enable/disable thread dispatch.
Is not this enough?

Thanks again.


On Tuesday 23 October 2007 15:12, Tim Cussins wrote:
> > I do not believe that someone will look into the following description of
> > theproblem, but may be this is in the area of known problems in 4.7 and I
> > simply waste my time...:-)
> >
> >
> >
> >
> > I have two tasks working on the same partition - taking buffers and
> > returning
> > back. Buffers are all of the same size.
> >
> > When the tasks are working sequentially, everything is OK.
> > But when I make them to work in parallel (one may interrupt the other),
> > very
> > quickly I receive the exception on rtems_partition_get_buffer, which
> > shows me
> > (after diving into the rtems code) that the element
> > the_partition->Memory.first has garbage value (all the rest of the
> > structure
> > looks normal).
>
> Sounds to me like you need to protect your accesses to the partition
> with a mutex...
>
> You may have run across one of the fundamental issues with
> multi-threading - two threads that need to share a resource (ie your
> "the_partition" structure) - if one thread is in the middle of modifying
> the structure and is interrupted, the stucture could easily be in an
> invalid (garbage) state when the other thread looks at it.
>
> You'll probably need to add code to each thread that acquires a mutex
> (shared between the threads, ie "the_partition_mutex") before operating
> on "the_partition" using the rtems_partition_get_buffer(). Of course it
> will have to release the mutex after it is done.
>
> In this way access to the_partition is serialised (only one thread can
> be modifying it at any time). Have a look on google/wikipedia for info
> on mutexes and critical sections.
>
> > I tried to catch this with my bdm debugger, but after one full day I gave
> > up -
> > too complex to catch this at the moment of corruption as this value
> > changes
> > all the time.
>
> yeah, good luck trying to catch that one! :P

-- 
            Dr.Leon M.Pollak
                Director
       PLR Information Systems Ltd.
Tel.:+972-98657670  |  POB 8130, H'Aomanut 9,
Fax.:+972-98657621  |  Poleg Industrial Zone,
Mob.:+972-544739246 |  Netanya, 42160, Israel.