leonp at plris.com
Tue Oct 23 13:30:53 UTC 2007
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?
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
PLR Information Systems Ltd.
Tel.:+972-98657670 | POB 8130, H'Aomanut 9,
Fax.:+972-98657621 | Poleg Industrial Zone,
Mob.:+972-544739246 | Netanya, 42160, Israel.
More information about the users