I am happy to do some work to clean up this code, but I don't think you have pointed to any 'real' problems (though I have to admit I have not really paged back in this code)
1. For concurrentCollection, there is synchronization between the controller and gc threads, and the value isn't allowed to be cached across the lock/unlock sequences.
2. For requestFlag, the check is safe because there is stronger synchronization required for the value change back from true to false---any thread that is out of date will see the stale (false) value but find the real value after acquiring the lock which is safe.
One thing we rely on here for both cases is that the compilers treat the lock/unlock calls as barriers for code motion. If lock() did not prevent the read of requestFlag from moving up before the lock() then things could get quite nasty!