Re: Usage of Semaphore with a workqueue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

On 14:45 Fri 03 Apr     , Peter Teoh wrote:
> Er....yes, i understand what u are saying.....but then I am lost over
> your original question.
> 
> Can you re-explain your original question again?   Now I don't quite understand.

Devesh wanted to do trylock of a semaphore inside a workqueue and return
ERESTARTSYS if locking fails. There are some things which are wrong with
this approach.

1) Mutexes should be prefered over semaphores, if possible. If it is not
possible, it might be a case which is not well suited for a workqueue. e.g.
you can create a request queue and use a semaphore for counting the number of
requests in the queue and sleeping if there are no requests until one arrives.

2) I have never used trylock and I still do not know what he wants to do with
it.

3) ERESTARTSYS is for use with the _interruptable functions of mutex_lock
and others. It makes only sense inside system calls, because its purpose is
to exit the system call prematurely in order to let a signal be delivered to
the user space process. The system call will then fail with errno set to
EINTR.
3.1) Returning ERESTARTSYS in a workqueue will not not work. The workqueue
function has to return void, so the return code will get lost. 
3.2) Returning ERESTARTSYS is only valid for the _interruptable functions if
a signal is pending. Returning it after trylock if something is currently
locked will not work (why would you want to do this anyway?).

        -Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com


--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux