Transactions and watches

Transactions and watches

[Jacob Gorm Hansen]

hi,

in my experimentation with xenbus, it seems that I get markedly
different results when using straigth xs_write's rather than nesting
them inside transactions. I suppose that the idea is that the watches
get triggered on transaction_end, but even if I enclose each xs_write
in it's own transaction I get different results.

Are transactions working the way they are supposed to, or is my
understanding wrong?

Jacob

--
Save time and bandwidth with EDelta: http://www.diku.dk/~jacobg/edelta/

Re: Transactions and watches

[Keir Fraser]

On 5 Oct 2005, at 17:44, Jacob Gorm Hansen wrote:

> in my experimentation with xenbus, it seems that I get markedly
> different results when using straigth xs_write's rather than nesting
> them inside transactions. I suppose that the idea is that the watches
> get triggered on transaction_end, but even if I enclose each xs_write
> in it's own transaction I get different results.
>
> Are transactions working the way they are supposed to, or is my
> understanding wrong?

Can you give a simple concrete example?

  -- Keir

Re: Transactions and watches

[Jacob Gorm Hansen]

Hmm it is not too simple, but if I run the code below as is, domU
succeeds in connecting netfront<->netback, e.g. there is no timeout
and the
MAC address is set correctly. If I rem in the xs_transaction_* calls,
the backend does not get the probe callback and nothing works.

Similar is true if I wrap each xs_write in a transaction_start-end pair.

    char s[256];
    char s2[256];

    int vifid = 2000 + domid;

    char* dom0_home = xs_get_domain_path(xs,0);
    printf("dom0_home is %s\n",dom0_home);

    char backend[256];
    char frontend[256];
    sprintf(backend,"%s/backend/vif/%d/%d",dom0_home,vifid,domid);
    sprintf(frontend, "%s/device/vif/%d",home,vifid);


    //xs_transaction_start(xs);

    sprintf(s,"%s/frontend",backend);
    xs_w(s, frontend );

    sprintf(s,"%s/frontend-id",backend);
    sprintf(s2,"%d",domid);
    xs_w(s, s2 );

    sprintf(s,"%s/handle",backend);
    sprintf(s2,"%d",vifid);
    xs_w(s, s2);


    //xs_transaction_end(xs,0);

    //xs_transaction_start(xs);


    sprintf(s, "%s/backend-id", frontend);
    xs_w(s, "0");

    sprintf(s,"%s/backend",frontend);
    xs_w(s, backend );

    sprintf(s,"%s/handle",frontend);
    sprintf(s2,"%d",vifid);
    xs_w(s, s2);

    sprintf(s,"%s/mac",frontend);
    xs_w(s, "aa:00:00:11:a6:02");

    //xs_transaction_end(xs,0);

Jacob

Re: Transactions and watches

[Anthony Liguori]

What snapshot of unstable are you using?

The only thing different about transactions is that slow things down a 
bit.  It would indicate you're seeing race conditions.

Note, that I've not been able to recreate the problems you're having 
with your code.  What OS are you using?  Do you have patches against 
unstable?

Regards,

Anthony Liguori

Jacob Gorm Hansen wrote:

>Hmm it is not too simple, but if I run the code below as is, domU
>succeeds in connecting netfront<->netback, e.g. there is no timeout
>and the
>MAC address is set correctly. If I rem in the xs_transaction_* calls,
>the backend does not get the probe callback and nothing works.
>
>Similar is true if I wrap each xs_write in a transaction_start-end pair.
>
>    char s[256];
>    char s2[256];
>
>    int vifid = 2000 + domid;
>
>    char* dom0_home = xs_get_domain_path(xs,0);
>    printf("dom0_home is %s\n",dom0_home);
>
>    char backend[256];
>    char frontend[256];
>    sprintf(backend,"%s/backend/vif/%d/%d",dom0_home,vifid,domid);
>    sprintf(frontend, "%s/device/vif/%d",home,vifid);
>
>
>    //xs_transaction_start(xs);
>
>    sprintf(s,"%s/frontend",backend);
>    xs_w(s, frontend );
>
>    sprintf(s,"%s/frontend-id",backend);
>    sprintf(s2,"%d",domid);
>    xs_w(s, s2 );
>
>    sprintf(s,"%s/handle",backend);
>    sprintf(s2,"%d",vifid);
>    xs_w(s, s2);
>
>
>    //xs_transaction_end(xs,0);
>
>    //xs_transaction_start(xs);
>
>
>    sprintf(s, "%s/backend-id", frontend);
>    xs_w(s, "0");
>
>    sprintf(s,"%s/backend",frontend);
>    xs_w(s, backend );
>
>    sprintf(s,"%s/handle",frontend);
>    sprintf(s2,"%d",vifid);
>    xs_w(s, s2);
>
>    sprintf(s,"%s/mac",frontend);
>    xs_w(s, "aa:00:00:11:a6:02");
>
>    //xs_transaction_end(xs,0);
>
>Jacob
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: Transactions and watches

[Jacob Gorm Hansen]

On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
> What snapshot of unstable are you using?
>
> The only thing different about transactions is that slow things down a
> bit.  It would indicate you're seeing race conditions.
>
> Note, that I've not been able to recreate the problems you're having
> with your code.  What OS are you using?  Do you have patches against
> unstable?

Hmm perhaps this is due to me being on a single CPU without SMT? Could
explain why my races are different?

Jacob

Re: Transactions and watches

[Anthony Liguori]

Jacob Gorm Hansen wrote:

>On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
>  
>
>>What snapshot of unstable are you using?
>>
>>The only thing different about transactions is that slow things down a
>>bit.  It would indicate you're seeing race conditions.
>>
>>Note, that I've not been able to recreate the problems you're having
>>with your code.  What OS are you using?  Do you have patches against
>>unstable?
>>    
>>
>
>Hmm perhaps this is due to me being on a single CPU without SMT? Could
>explain why my races are different?
>  
>
I'm also on a single CPU w/o SMT :-)

Regards,

Anthony Liguori

>Jacob
>
>  
>