[SOLVED] Should I implement ILockBytes::LockRegion/UnlockRegion if my program will not access the memory concurrently?

Should I implement ILockBytes::LockRegion/UnlockRegion if my program will not access the memory concurrently?

I am implementing a ILockBytes (C++) interface to save IStorage as a byte array. ILockBytes must support LockRegion and UnlockRegion methods.
I can guarantee, that my program which implements ILockBytes for StgCreateDocfileOnILockBytes, will not read/write ILockbytes's memory in parallel (concurrently) itself.
Should I implement Lock/Unlock anyway ?
In other words - can another program (OS) try to access this memory concurrently ?

Solution

Pretty clear manual:

To determine the lock types supported by a particular ILockBytes implementation, you can examine the grfLocksSupported member of the STATSTG structure returned by a call to ILockBytes::Stat.

A LockRegion implementation can choose to support all, some, or none of the lock types. For unsupported lock types, the implementation should return STG_E_INVALIDFUNCTION.

You should implement ILockBytes::Stat that sets 0 to STATSTG::grfLocksSupported indicating no locks are supported and you should implement ILockBytes::LockRegion that returns STG_E_INVALIDFUNCTION.