git » libjio » commit 5e8ba2e

Trying to lock fs->lock inside jclose() is useless and counterproductive, because the race with pthread_mutex_destroy() is unavoidable, and the caller must take care of not calling jclose() concurrently anyways.

author Alberto Bertogli
2004-08-29 00:46:03 UTC
committer Alberto Bertogli
2007-07-15 13:17:16 UTC
parent 0b1297f6448891b2f99fcd1ae97fc349db36e2f4

Trying to lock fs->lock inside jclose() is useless and counterproductive, because the race with pthread_mutex_destroy() is unavoidable, and the caller must take care of not calling jclose() concurrently anyways.

Trying to lock fs->lock inside jclose() is useless and counterproductive,
because the race with pthread_mutex_destroy() is unavoidable, and the caller
must take care of not calling jclose() concurrently anyways.

trans.c +0 -2

diff --git a/trans.c b/trans.c
index 983dc46..13e7b8e 100644
--- a/trans.c
+++ b/trans.c
@@ -625,7 +625,6 @@ int jclose(struct jfs *fs)
 	int ret;
 
 	ret = 0;
-	pthread_mutex_lock(&(fs->lock));
 
 	if (jsync(fs))
 		ret = -1;
@@ -641,7 +640,6 @@ int jclose(struct jfs *fs)
 	if (fs->jmap != MAP_FAILED)
 		munmap(fs->jmap, sizeof(unsigned int));
 
-	pthread_mutex_unlock(&(fs->lock));
 	pthread_mutex_destroy(&(fs->lock));
 
 	return ret;