On Wed, Apr 13, 2022 at 6:24 PM Henry Rich <[email protected]> wrote:
> Yes, opening a pyx-in-error signals error as usual and if suspension is
> enabled, the system (all threads) will go into suspension.
>
> If we detected deadlock, we could treat that as completing the
> deadlocked pyxes with an error result. I'm not sure how easy it is to
> find them.
This might turn into a "best effort" situation.
That said, conceptually locking is about temporarily turning a
multi-threaded program into a single threaded program and perhaps we
could leverage that concept.
> Also, you can have a 'livelock', where the tasks are waiting for each
> other but not through pyxes (through global names).
Ideally, a mutex implementation should be able to identify which
thread is being waited on, and when a lock cannot be acquired that
should be inspectable. That might mean using the pthread mutex in
non-blocking mode to acquire a j specific mutex.
> Perhaps the best thing is to let the usual break into the system if they
> suspect a deadlock. It seems unlikely that a user will create a
> deadlock accidentally - the cases we have seen would give errors if run
> on a single-threaded system.
In J904 without spawning theads:
a=: {{> ". 'a' [ 6!:3]2}}t.'' 0
$>a
0
I guess this is because of how ".'undefined' works... But, anyways,
stuff gets strange sometimes.
FYI,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
