How to send a response back if a function is locked using mutex.lock() in Golang?

I have this function.

func (s *eS) Post(param *errorlogs.Q) (*errorlogs.Error, *errors.RestErr) {
//sub := q.Get("sub")
s.mu.Lock()
utime := int32(time.Now().Unix())
// Open our jsonFile
jsonFile, errFile := getlist(param.Id)
// if we os.Open returns an error then handle it
if errFile != nil {
return nil, errFile
}
jsonFile, err := os.Open(dir + "/File.json")
// if we os.Open returns an error then handle it
if err != nil {
return nil, errors.NewNotFoundError("Bad File request")
}
// read our opened jsonFile as a byte array.
byteValue, _ := ioutil.ReadAll(jsonFile)
// we initialize our  model
var errorFile errorlogs.Error_File
// we unmarshal our byteArray which contains our
// jsonFile's content into '' which we defined above
json.Unmarshal(byteValue, &errorFile)
// defer the closing of our jsonFile so that we can parse it later on
defer jsonFile.Close()
// An object to copy the required data from the response
var id int32
if len(errorFile.Error) == 0 {
id = 0
} else {
id = errorFile.Error[len(errorFile.Error)-1].ID
}
newValue := &errorlogs.Error{
ID:         id + 1,
Utime:      utime,
}
errorFile.Error = append(errorFile.Error, *newValue)
file, err := json.Marshal(errorFile)
if err != nil {
return nil, errors.NewInternalServerError("Unable to json marshal file")
}
err = ioutil.WriteFile(dir+"/File.json", file, 0644)
if err != nil {
return nil, errors.NewInternalServerError("Unable to write file")
}
s.mu.Unlock()
return newValue, nil
}

Here i am locking this function from the concurrent request that if some client is already writing to the file it will not let the other client write to it at the same time. But now i have confusion that what does this mutex.Lock() does to all the other requests while it is being locked? does it let the other client wait? or it just ignore all the other clients? do we have any way of sending back the client with some kind of response? or let the other client wait and then allow them to access this function ?

When a mutex is locked, all other calls to Mutex.Lock() will block until Mutex.Unlock() is called first.

So while your handler is running (and holding the mutex), all other requests will get blocked at the Lock() call.

Note: if your handler doesn't complete normally because you return early (using a return statement), or it panics, your mutex will remain locked, and hence all further requests will block.

A good practice is to use defer to unlock a mutex, right after it is locked:

s.mu.Lock()
defer s.mu.Unlock()

This ensures Unlock() will be called no matter how your function ends (may end normally, return or panic).

Try to hold the lock for as little time as possible to minimize blocking time of other requests. While it may be convenient to lock right as you enter the handler and only unlock before return, if you don't use the protected resources for the "lifetime" of the handler, only lock and unlock when you use the shared resource. For example if you want to protect concurrent access to a file, lock the mutex, read / write the file, and as soon as you're done with it, unlock the mutex. What you do with the read data and how you assemble and send your response should not block other requests. Of course when using defer to unlock, that may not run as early as it should be (when you're done with the shared resource). So in some cases it may be OK not to use defer, or the code accessing shared resources may be moved to a named or unnamed (anonymous) function to still be able to use defer.

sync.Mutex does not support "peeking" the status, nor "try-lock" operation. This means using sync.Mutex you cannot signal the client that it has to wait because processing the request is waiting another request to complete. If you'd need such functionality, you could use channels. A buffered channel with a capacity of 1 could fulfil this functionality: the "lock" operation is sending a value on the channel, the "unlock" operation is receiving a value from the channel. So far so good. The "try-lock" operation could be a "conditional" send operation: using a select statement with a default case, you could detect that you can't lock now because it is already locked, and you could do something else instead or meanwhile, and retry locking later.

Here's an example how it could look like:

var lock = make(chan struct{}, 1)
func handler(w http.ResponseWriter, r *http.Request) {
// Try locking:
select {
case lock <- struct{}{}:
// Success: proceed
defer func() { <-lock }() // Unlock deferred
default:
// Another handler would block us, send back an "error"
http.Error(w, "Try again later", http.StatusTooManyRequests)
return
}
time.Sleep(time.Second * 2) // Simulate long computation
io.WriteString(w, "Done")
}
func main() {
http.HandleFunc("/", handler)
log.Fatal(http.ListenAndServe(":8080", nil))
}

The above simple example returns an error immediately if another request holds the lock. You could choose to do different things here: you could put it in a loop and retry a few times before giving up and returning an error (sleeping a little between iterations). You could use a timeout when attempting to lock, and only accept "failure" if you can't get the lock for some time (see time.After() and context.WithTimeout()). Of course if we're using a timeout of some sort, the default case must be removed (the default case is chosen immediately if none of the other cases can proceed immediately).

And while we're at it (the timeout), since we're already using select, it's a bonus that we can incorporate monitoring the request's context: if it's cancelled, we should terminate and return early. We may do so by adding a case receiving from the context's done channel, like case <-r.Context().Done():.

Here's an example how timeout and context monitoring could be done simply with a select:

var lock = make(chan struct{}, 1)
func handler(w http.ResponseWriter, r *http.Request) {
// Wait 1 sec at most:
ctx, cancel := context.WithTimeout(r.Context(), time.Second) 
defer cancel()
// Try locking:
select {
case lock <- struct{}{}:
// Success: proceed
defer func() { <-lock }() // Unlock deferred
case <-ctx.Done():
// Timeout or context cancelled
http.Error(w, "Try again later", http.StatusTooManyRequests)
return
}
time.Sleep(time.Second * 2) // Simulate long computation
io.WriteString(w, "Done")
}