Re: synchronisation question

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

 



On 8/30/05, Jan Hudec <bulb@xxxxxx> wrote:
> On Tue, Aug 30, 2005 at 17:50:27 +0530, Gaurav Dhiman wrote:
> > On 8/30/05, Jan Hudec <bulb@xxxxxx> wrote:
> > (actually, there is at least one point where preempt is _worse_ than SMP --
> > > ordering of set_current_state, waitqueue_add and schedule() worked on SMP,
> > > but it does NOT work on preempt).
> >
> > Can you elaborate on this more, I could not get the meaning of it.
> 
> Compare the wait_event macro in 2.4 and in 2.6. From plain trivial in 2.4, it
> changed to quite complex beast in 2.6, because of preempt. And IIRC there
> were some places where similar tricks to wait_even were used in 2.4, which is
> not so easy now.


I compared the  wait_event macro in 2.4 and 2.6 kernel.  Things are
bit different on 2.6. now wait_queue_t structure have one more
element, which is call back function. As far as I can guess this is
the corresponding function which will be used to wake up the process,
in 2.4 we do not used to give this, rather we used to call the wake up
function explicitly. Could you tell where this call back function is
used or called from ?

If we look into the 2.6 implementation of wait_event macro, its as follows:

159 #define __wait_event(wq, condition)                                     \
160 do {                                                                    \
161         DEFINE_WAIT(__wait);                                            \
162                                                                         \
163         for (;;) {                                                      \
164                 prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);    \
165                 if (condition)                                          \
166                         break;                                          \
167                 schedule();                                             \
168         }                                                               \
169         finish_wait(&wq, &__wait);                                      \
170 } while (0)

Here in place of directly updating the state field of task_struct
structure, we call prepare_to_wait() and finish_wait() functions. I
think, implementations of these two functions is not doing anything
extra except one tihng in prepare_to_wait() function. In
prepare_to_wait() we do add the wait queue element on wait queue but
update the state of the current task only if is_sync_wait() function
returns true on on wait element. Now the question is what is this new
concept of sync wait and async wait and why we are not updating the
task state form TASK_RUNNING to TASK_UNINTERRUPTIBLE in all cases. As
we do not remove the current process from runqueue and also not
changing the state of current task from TASK_RUNNING to
TASK_UNINTERRUPTIBLE, wont this allow our current task to be
schedulable, which we dont want.

Well in 2.4 kernel, there we used to sync or sync wake up calls, but I
think this something different from what mentioned above.

-Gaurav

> --
>                                                  Jan 'Bulb' Hudec <bulb@xxxxxx>
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDFGEyRel1vVwhjGURAv90AJ9RslZSUh3w9XgYBzVryuZamvSQSwCgzLNX
> F0JGj8T5x5nSsgXEVnVP7yA=
> =Fqb1
> -----END PGP SIGNATURE-----
> 
> 
>

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           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