From: Daniel Lehman <dlehman@esri.com>
Subject: RE: [PATCH 6/6] msvcp140_atomic_wait: Implement __std_bulk_submit_threadpool_work.
Message-Id: <CO6PR05MB75067A9EA974AB19C02BC913DF219@CO6PR05MB7506.namprd05.prod.outlook.com>
Date: Thu, 27 Jan 2022 15:04:53 +0000
In-Reply-To: <27c54241-0aa7-6094-6f00-def4230762a5@gmail.com>
References: <CO6PR05MB7506EB7C2068E09751A521A8DF209@CO6PR05MB7506.namprd05.prod.outlook.com> <27c54241-0aa7-6094-6f00-def4230762a5@gmail.com>

> The workcalled < 1234 occasionally fails on my machine (and if it doesn't we end with workcalled around 1230). Please remove the test or find a way to avoid the race.
I wanted a way to show the 2nd argument was really a cancel, but wasn't sure about the best way.  the 1234 seemed to work consistently for my box - would a higher number be ok?   if not, would removing the test for now be ok, to avoid random failures?

> Please also use InterlockedIncrement when updating workcalled from multiple threads.
Ah, right.  will do

Thanks
daniel