Forum OpenACS Q&A: developer-friendly mutexing

I've put my ad_mutex library up here. It handles the logistics of putting the mutexes in nsvs and doing the lock/unlocks. E.g.

in your library code: ad_mutex_init users

in your scripts:

ad_with_mutex users [ad_get_user_id] {
    ...
}

would give you one mutex per user so they're not blocking each other out like you would with a single global mutex.

that's exactly right. like my library doc says,

# This allows us to easily make our locking as fine-grained as we want
# -- each set/key combination identifies a unique mutex.

# Mutexing becomes useful whenever you want to make sure different
# interpreters aren't steping on each others' toes.  E.g. for
# on-demand ("lazy") data loading, like the original util_memoize.
# Or when your script follows the "if A, then B" pattern, where executing B
# potentially makes A no longer true, and you want to make sure that multiple
# requests for the script can't cause B to execute many times by different
# threads grabbing the same value of A before any of them execute B.

For carnageblender almost all the places I use ad_with_mutex would cripple throughput if I had to use a Big Hammer of a single global mutex. Although I sometimes do use a Big Hammer; that is easier and more readable with ad_with_mutex than with rolling them manually, as well.