SHARED locks barging behaviour

I'm trying to better understand the following barging behaviour with SHARED
locks.

*Setup:*

postgres=# create table t(a INT);
CREATE TABLE
postgres=# INSERT INTO t VALUES(1);
INSERT 0 1

Then, performing the following operations in 3 different sessions, in
order, we observe:

Session 1 Session 2 Session 3
BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR SHARE;
a
---
1
(1 row)
postgres=# BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR UPDATE;

* --- waits
BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR SHARE;
a
---
1
(1 row)

* -- returns immediately

Given there is a transaction waiting to acquire a FOR UPDATE lock, I was
surprised to see the second FOR SHARE transaction return immediately
instead of waiting. I have two questions:

1) Could this barging behaviour potentially starve out the transaction
waiting to acquire the FOR UPDATE lock, if there is a continuous queue of
transactions that acquire a FOR SHARE lock briefly?
2) Assuming this is by design, I couldn't find (in code) where this
explicit policy choice is made. I was looking around LockAcquireExtended, but
it seems like the decision is made above this layer. Could someone more
familiar with this code point me at the right place?

Thanks