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

Re: [Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: event management [and 1 more messages]



[Ian Jackson:] 
> I'm not sure how that would help.  libxl already has a mutex which it takes
> on entry, so all calls into libxl are already mututally exclusive.
> 
> What would happen if your fd registration callback ocaml code tried to make
> a libxl call ?

Ok, what I said was not quite right. You are referring to the fact that libxl 
keeps hold of its lock in the fd registration callback. A possible deadlock 
scenario like the following may then occur:

Thread 1                                Thread 2
========                                ========

xenopsd thread starts                   .
    acquire ocaml heap lock             .
                                        .
xenopsd calls libxl                     .
    acquire libxl lock                  .
                                        .
libxl asks xenopsd to register fd       .
                                        .
xenopsd does blocking write             .
    drop ocaml heap lock                .
    write()                             .
                                        .
                                        xenopsd thread starts
                                            acquire ocaml heap lock
                                        .
                                        xenopsd calls libxl
                                            acquire libxl lock
                                            ==> held by thread 1

    acquire ocaml heap lock
    ==> held by thread 2


The experts here have suggested that the common thing to do is to release the 
ocaml heap lock when calling libxl functions, and reaquire it when returning or 
calling back into ocaml. I tried to avoid this, because it complicates things, 
but it seems I have no choice now :)

In this case, the ocaml heap lock is never held together with the libxl lock, 
except in the registration callbacks. If we then promise to not call any libxl 
functions inside the callback, I think we can avoid deadlocks.

The picture becomes as follows:

Thread 1                                Thread 2
========                                ========

xenopsd thread starts                   .
    acquire ocaml heap lock             .
                                        .
xenopsd calls libxl                     .
    drop ocaml heap lock                .
    acquire libxl lock                  .
                                        .
libxl asks xenopsd to register fd       .
    acquire ocaml heap lock             .
                                        .
xenopsd does blocking write             .
    drop ocaml heap lock                .
    write()                             .
                                        .
                                        xenopsd thread starts
                                            acquire ocaml heap lock
                                        .
                                        xenopsd calls libxl
                                            drop ocaml heap lock
                                            acquire libxl lock
                                        .
    acquire ocaml heap lock             .
                                        .
return to libxl                         .
    drop ocaml heap lock                .
                                        .
return to xenopsd                       .
    drop libxl lock                     .
    acquire ocaml heap lock             .
                                        .
                                        return to xenopsd
                                            drop libxl lock
                                            acquire ocaml heap lock

...and all is ok.

Does that sound right?

How about event_occurs callback, and async callbacks? Is the situation the same?

Thanks,
Rob

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.