Re: pcp updates: libpcp multithreading - documentation and tools for call graphs & lock analysis

On 10/01/17 08:12, Frank Ch. Eigler wrote:
>
> kenj wrote:
>
>> [...]
>>  src/libpcp/doc/glibc.unsafe       |   17 +
>> [...]
>>         The algorithm here is a leaf to root approach to removing nodes
>>         that are themselves unconditionally thread-safe (meaning they acquire
>>         no locks and call only thread-safe routines), and remove all incoming
>>         arcs to these nodes.
>> [...]
>
> It sounds like you're really keen on a "bottom-up" sort of approach to
> the problems, starting to look at how libpcp makes use of other
> libraries, rather than concurrency controls on its own internal shared
> data .  Then it becomes important to classify functions etc.  properly
> in the libpcp/doc/*.{safe,unsafe} lists, so that no effort is wasted or
> missed.

I am starting at the "bottom" for a couple of reasons ...
- there is no need to use __pmLock_libpcp in those cases where we only 
need mutual exclusion for the external call (because the external 
routine is not thread-safe)
- reducing the use of __pmLock_libpcp will make it easier to tackle the 
higher-level issues of concurrency control for the shared libpcp data

> So for example I wonder why the tsearch* related functions are listed in
> glibc.unsafe.  These do not refer to shared state within another
> library, so don't have nor need internal concurrency controls.  In the
> way we call them in libpcp (pdubuf), we hold -a- lock to denote the
> critical section of the shared libpcp data (the tree root pointers).

Including the tree search family in glibc.unsafe is a mistake on my part 
... I'm using the GNU documentation and I simply misread the safety 
properties (MT-Safe race:rootp) ... I've moved these routines to 
glibc.safe as the rootp race cannot happen for our use cases.

> Yes, this lock shouldn't be the big libpcp lock (and isn't in the
> fche/multithread branch), but that's not because of tsearch* etc. being
> somehow unsafe.  In this context, they're exactly as safe or unsafe as
> any other operation on a shared pointer - as a C level assignment or
> dereference or whatever.
>
> Maybe the .unsafe lists should only include functions that are
> inherently MT-unsafe (such as fighting over hidden shared data), which
> -must- be protected with some auxiliary lock, no matter what.  The
> pdubuf's subsystem's use of tsearch* wouldn't be in that category.

Agreed.

Thanks for the feedback, Frank.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14962): https://groups.io/g/pcp/message/14962
View All Messages In Topic (6): https://groups.io/g/pcp/topic/3819767
Mute This Topic: https://groups.io/mt/3819767?uid=174580
New Topic: https://groups.io/g/pcp/post
-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580
Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]
Terms of Service: https://groups.io/static/tos
Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-