* [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock when
@ 2006-02-06 5:52 Jim Cromie
2006-02-06 10:17 ` [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock Jean Delvare
0 siblings, 1 reply; 2+ messages in thread
From: Jim Cromie @ 2006-02-06 5:52 UTC (permalink / raw)
To: lm-sensors
From: Jim Cromie <jim.cromie at gmail.com>
Modifies pc87360_update_device() to avoid locking & unlocking
when data is not actually being resampled. Also re-indented
the body of the function, removing the now extra tabs.
Signed-off-by: Jim Cromie <jim.cromie at gmail.com>
----
patch applies over:
linux-2.6.16-rc1-mm4
+ hwmon-pc87360-use-sensor-attr-2.patch
+ hwmon-pc87360-sysfs-combo-callbacks.patch
or without the 2 patches, with (offset -34 lines).
$ diffstat hwmon-pc87360-lock-only-when-sampling.patch
pc87360.c | 158
+++++++++++++++++++++++++++++++-------------------------------
1 files changed, 79 insertions(+), 79 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hwmon-pc87360-lock-only-when-sampling.patch
Type: text/x-patch
Size: 6213 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060206/ebddd2e9/hwmon-pc87360-lock-only-when-sampling-0001.bin
^ permalink raw reply [flat|nested] 2+ messages in thread
* [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock
2006-02-06 5:52 [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock when Jim Cromie
@ 2006-02-06 10:17 ` Jean Delvare
0 siblings, 0 replies; 2+ messages in thread
From: Jean Delvare @ 2006-02-06 10:17 UTC (permalink / raw)
To: lm-sensors
Hi Jim,
On 2006-02-06, Jim Cromie wrote:
> Modifies pc87360_update_device() to avoid locking & unlocking
> when data is not actually being resampled. Also re-indented
> the body of the function, removing the now extra tabs.
Imagine that two user-space processes read sysfs files and trigger the
update, at the same time. With the original locking model, both
processes will attempt to get the lock. One only (A) will succeed, while
the other (B) will have to wait. (A) will then test the time condition,
and update the data if needs be, then release the lock. At this point,
(B) will be granted the lock, and will get to test the time condition.
As (A) just updated the timestamp, (B) will skip the update as intended,
and release the lock immediately.
With your changes, (A) and (B) will test the time condition concurrently.
If an update is needed, they will fight for the lock. (A) will get it
and do the update, then release the lock. Then (B) will get it and do
the update again! Then release the lock. So you actually had two
consecutive updates, while the caching mecanism precisely tries to avoid
this.
So this doesn't work, sorry.
--
Jean Delvare
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-02-06 10:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-06 5:52 [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock when Jim Cromie
2006-02-06 10:17 ` [lm-sensors] [patch 1/1] hwmon-pc87360 : avoid lock & unlock Jean Delvare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.