Is this a good design for a package?

I want to use a sync.RWMutex as a local variable inside a package that copies/moves/deletes files and then (in simple terms) updates the state of the paths in other local maps.

So I decided to create the local mutex and leave this comment in it:

// To block/unblock when performing reads and writes in blogs.
// mu should only be used in exportable functions that perform reads and writes
// in memory (i.e. someXMap and someYMap) and in the filesystem, non-exportable
// functions that also perform such reads/writes should not use mu but its
// caller which mandatorily must be an exportable function.
// In short, the non-exportable functions that make reads/writes in the blogs
// can only be called by an exportable function that uses mu.
mu sync.RWMutex

I wonder what another developer would think when he gets to work with this package and reads that mu should only be used in exportable functions, is it a rational design?, or should I strive to find another better method?

  1. What is the product being packaged? Knowing the product will help me understand the functionality and aesthetic needs of the design.


I want to know if my approach will avoid race conditions.

  • What are the goals of the design? (e.g., attract attention, convey information, be easy to open)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.