Soumya Koduri 7f4b42e7ae gfapi: Suspend synctasks instead of blocking them ...

There are certain conditions which blocks the current
execution thread (like waiting on mutex lock or condition
variable or I/O response). In such cases, if it is a
synctask thread, we should suspend the task instead
of blocking it (like done in SYNCOP using synctask_yield)

This is to avoid deadlock like the one mentioned below -

1) synctaskA sets fs->migration_in_progress to 1 and
   does I/O (LOOKUP)
2) Other synctask threads wait for fs->migration_in_progress
  to be reset to 0 by synctaskA and hence blocked
3) but synctaskA cannot resume as all synctask threads are blocked
   on (2).

Note: this same approach is already used by few other components
like syncbarrier etc.

Change-Id: If90f870d663bb242c702a5b86ac52eeda67c6f0d
Fixes: #1146
Signed-off-by: Soumya Koduri <skoduri@redhat.com>
(cherry picked from commit 55914f968d)

2020-04-16 06:36:22 +00:00

..

examples

Land part 2 of clang-format changes

2018-09-12 17:52:45 +05:30

src

gfapi: Suspend synctasks instead of blocking them

2020-04-16 06:36:22 +00:00

Makefile.am

gfapi.py: support dynamic loading of versioned libraries

2013-10-02 13:04:03 -07:00