RFR: CODETOOLS-7903021: jcstress: Dining Philosophers problem sample

Michael Mirwaldt github.com+6693355+mmirwaldt at openjdk.java.net
Mon Oct 11 13:52:19 UTC 2021


On Mon, 20 Sep 2021 08:18:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I get more and more the feeling this sample and the next samples following are too sophisticated for JCStress because they just need too many actors. 
>> You wrote in one of your emails JCStress only supports at most 4 actors, better only 3 actors at most. 
>> While the Dining Philosophers sample would run with 3 actors, I don't think this will work for the next samples following. I am afraid the reader-writer problem will never run with only 4 actors because overhead of the locking protocol destroys all results.
>> 
>> Do you want to focus on the JMM samples, the CAS samples and the Mutex samples which don't need many actors in JCStress  or do you also want to support sophisticated lock protocols which will need more than 4 actors in future?
>> If the answer is "No, JCStress will never support more than 4 actors because ...", then I would not add this sample and the others because they don't make much sense. It would invite users to use JCStress for use cases it was not made.
>
>> While the Dining Philosophers sample would run with 3 actors, I don't think this will work for the next samples following. I am afraid the reader-writer problem will never run with only 4 actors because overhead of the locking protocol destroys all results.
> 
> My point is to use the minimum number of actors that still makes the test viable. For Dining Philosophers, it seems three threads are enough. We shall address the reader-writer thread problem, when we come to that.

Any update, @shipilev?
I guess you have been very busy recently and overlooked my changes here ;-)

-------------

PR: https://git.openjdk.java.net/jcstress/pull/93


More information about the jcstress-dev mailing list