[RTEMS Project] #2957: Shared memory support internal locking is broken

[RTEMS trac]

#2957: Shared memory support internal locking is broken
-----------------------------+-----------------------
 Reporter:  Sebastian Huber  |       Owner:  Gedare
     Type:  defect           |      Status:  assigned
 Priority:  normal           |   Milestone:  4.12
Component:  cpukit           |     Version:  4.12
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+-----------------------

Comment (by Sebastian Huber):

 Replying to [comment:1 Gedare]:
 > Yes: the shm code has some rather questionable design choices in its
 locking patterns. Here it acquires a thread_queue and then calls a user
 plugin function, in this case malloc is called which eventually leads to
 the error shown.
 >
 > Is there somewhere with guidance written for how to use the various lock
 constructs available in RTEMS? Or what are their constraints on use.
 Because I didn't even know this was a problem, and apparently did not
 spend much time thinking about this while writing the code.

 Good question, maybe we should something add to the manual, e.g. in Key
 Concepts, 3.3 Communication and Synchronization.


 >
 > The shm code uses 2 locking patterns. The one causing a problem here is
 the use of a thread_queue to protect the invocations to operations on the
 shared-memory object. This should be some fine-grained mutex lock that
 allows the operation invoked to also acquire/release internal locks such
 as is needed by malloc.

 The thread queue should be replaced with a mutex. For simplicity, maybe
 just the allocator mutex. We really need the self-contained mutexes for
 internal use.

 >
 > The other lock used is the _Objects_Allocator_lock to protect the
 integrity of the POSIX_Shm_Control Object. I think this one is fine.

 Yes.

--
Ticket URL: <http://devel.rtems.org/ticket/2957#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project