diff --git a/libraries/ghc-internal/src/GHC/Internal/IO/Handle/Lock.hs b/libraries/ghc-internal/src/GHC/Internal/IO/Handle/Lock.hs
index ce7d32c881a7a422db09989c90f0419cb4e646bd..63a0758970de4708e98f678e02f51fd0d130a73e 100644
--- a/libraries/ghc-internal/src/GHC/Internal/IO/Handle/Lock.hs
+++ b/libraries/ghc-internal/src/GHC/Internal/IO/Handle/Lock.hs
@@ -35,14 +35,20 @@ import GHC.Internal.IO.Handle.Lock.NoOp
 --
 -- Things to be aware of:
 --
--- 1) This function may block inside a C call. If it does, in order to be able
+-- 1. This function may block inside a C call. If it does, in order to be able
 -- to interrupt it with asynchronous exceptions and/or for other threads to
 -- continue working, you MUST use threaded version of the runtime system.
 --
--- 2) The implementation uses 'LockFileEx' on Windows and 'flock' otherwise,
+-- 2. The implementation uses relies on any of a number of locking
+-- facilities, depending upon what the platform supports:
+--
+--   * 'LockFileEx' is used on Windows
+--   * On platforms that support it we use the @F_OFD_SETLK@ and @F_OFD_SETLKW@ @fnctl@s.
+--   * Otherwise we use @flock@
+--
 -- hence all of their caveats also apply here.
 --
--- 3) On non-Windows platforms that don't support 'flock' (e.g. Solaris) this
+-- 3. On non-Windows platforms that don't support 'flock' (e.g. Solaris) this
 -- function throws 'FileLockingNotImplemented'. We deliberately choose to not
 -- provide fcntl based locking instead because of its broken semantics.
 --