Re: [PATCH 09/11] gdb: optimize selection of resumed thread with pending event

[Pedro Alves <pedro@palves.net>]

On 2021-06-22 5:57 p.m., Simon Marchi via Gdb-patches wrote:
> Consider a case where many threads (thousands) keep hitting a breakpoint
> whose condition evaluates to false.  random_pending_event_thread is
> responsible for selecting a thread from an inferior among all that are
> resumed with a pending wait status.  It is currently implemented by
> walking the inferior's thread list twice: once to count the number of
> candidates and once to select a random one.
> 
> Since we now maintain a per target list of resumed threads with pending
> event, we can implement this more efficiently by walking that list and
> selecting the first thread that matches the criteria
> (random_pending_event_thread looks for an thread from a specific
> inferior, and possibly a filter ptid).  It will be faster especially in
> the common case where there isn't any resumed thread with pending
> event.  Currently, we have to iterate the thread list to figure this
> out.  With this patch, the list of resumed threads with pending event
> will be empty, so it's quick to figure out.
> 
> The random selection is kept, but is moved to
> process_stratum_target::random_resumed_with_pending_wait_status.  The
> same technique is used: do a first pass to count the number of
> candidates, and do a second pass to select a random one.  But given that
> the list of resumed threads with pending wait statuses will generally be
> short, or at least shorter than the full thread list, it should be
> quicker.
> 
> Note that this isn't completely true, in case there are multiple
> inferiors on the same target.  Imagine that inferior A has 10k resumed
> threads with pending wait statuses, and random_pending_event_thread is
> called with inferior B.  We'll need to go through the list that contains
> inferior A's threads to realize that inferior B has no resumed threads
> with pending wait status.  But I think that this is a corner /
> pathological case.  And a possible fix for this situation would be to
> make random_pending_event_thread work per-process-target, rather than
> per-inferior.
> 
> gdb/ChangeLog:
> 
> 	* process-stratum-target.h (class process_stratum_target)
> 	<random_resumed_with_pending_wait_status>: New.
> 	* process-stratum-target.c
> 	(process_stratum_target::random_resumed_with_pending_wait_status):
> 	New.
> 	* infrun.c (random_pending_event_thread): Use
> 	random_resumed_with_pending_wait_status.

OK.