lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 02 Dec 2009 03:28:32 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: General kernel question about waiting for events

On Wed, 2009-12-02 at 00:24 +0000, Alan Cox wrote: 
> > In that case, wrapped in different packages, it always ends with
> > following loop:
> > 
> > while( event == false )
> > schedule();
> 
> No. If it were to do that then real time processes could spin eating the
> CPU forever.
> 
> There is a difference between rescheduling and sleeping for an event.
> Sleeping for an event (ie on a waitqueue) means that you will not be
> woken until the wait queue is woken (or certain other things like signals
> if interruptible). Rescheduling gives the CPU to someone else if anyone
> wants it.
> 
> In short the different task states that are set are the important bit to
> look at to understand this further.
Thanks you very much!

I already begin to investigate in that area, but your answer sums
everything up, sorry for silly (as I expected) question.

So, current task state is set to TASK_UNINTERRUPTIBLE or
TASK_INTERRUPTIBLE which differ in signal delivery (that I understood,
the TASK_INTERRUPTIBLE will break the wait when signal is received) but
both mean that current task is removed from scheduler pool until it is
woken up, or in case of schedule_timeout() also after the timeout
expires.
Also wait_event_interruptible_timeout does check the condition to avoid
useless sleeps, but if another thread or interrupt handler want to wake
it up, it not only sets that condition (it is optional at all) but
actually wakes the task up using literally wake_up() or related
functions.

Best regards,
Maxim Levitsky


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists