<br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 8:37 PM, krish <span dir="ltr"><<a href="mailto:kparthas@redhat.com" target="_blank">kparthas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>The strategy is to defer yield'ing of
the task till a mgmt operation is sent to all the peers.<br>
<br>
If I understand it right, the following theorem is true,<br>
- A function which begins execution in a synctask (ie. thread from
syncenv's thread pool), would always<br>
resume execution (ie, wake) in the same thread (viz. part of
syncenv's thread pool).<br></div></div></blockquote><div><br></div><div>Nope! A synctask can yield in one syncproc pthread and resume in a different one. But that should not matter for you as long as it is any one of those syncproc pthreads from the pool.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
If the above theorem is correct, then all syncops performed by
mgmt operation handlers are<br>
guaranteed to be called from a syncenv. The synctask is spawned at
rpcsvc layer for all glusterd mgmt<br>
operations programs.<br>
<br>
Following is an example code snippet. <br>
<br>
<code><br>
gd_lock_op_phase (struct list_head *peers, char **op_errstr, int
npeers) {<br>
<br>
....<br>
<br>
list_for_each_entry (peerinfo, peers, op_peers_list) {<br>
gd_syncop_mgmt_lock (peerinfo->rpc, aggr,
index,<br>
MY_UUID, peer_uuid);<br>
index++;<br>
}<br>
synctask_yield (aggr->task);<br>
//note: block in the above line until all the cbks return -
call_cnt mechanism<br>
<br>
....<br>
<br>
}<br>
<br>
#define GD_SYNCOP(rpc, stb, cbk, req, prog, procnum, xdrproc) do
{ \<br>
int ret =
0; \<br>
struct synctask *task =
NULL; \<br>
\<br>
task = synctask_get
(); \<br>
stb->task =
task; \<br>
ret = gd_syncop_submit_request (rpc, req,
stb, \<br>
prog, procnum,
cbk, \<br>
(xdrproc_t)xdrproc); \<br>
// note: yield here has been removed<br>
} while (0)<br>
<br>
</code><br>
<br></div></div></blockquote><div><br></div><div><br></div><div>Where/how is callcnt set, and decremented?</div><div><br></div><div>Avati</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
Let me know if we can come up with a generic framework for what I
am <br>
trying to do here.<br>
<br>
thanks,<br>
krish<div><div class="h5"><br>
<br>
On 02/14/2013 05:23 AM, Anand Avati wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">So you are not using the SYNCOP() macro, right? Can
you show a code snippet of how you are trying to fan-out and
yield? We could probably come up with a generic framework for such
fan-out->yield->wake pattern.
<div><br>
</div>
<div>You should be able to call syncop_yield() instead of
__yield() if you are _sure_ that the caller is going to be from
within a syncenv.</div>
<div><br>
</div>
<div>Avati<br>
<br>
<div class="gmail_quote">On Wed, Feb 13, 2013 at 11:29 AM,
Krishnan Parthasarathi <span dir="ltr"><<a href="mailto:kparthas@redhat.com" target="_blank">kparthas@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In
glusterd, I am trying to perform a series of syncops in a
batch. ie, yield the thread<br>
once all the non-blocking operations are queued. The wakeup
back to the yielded thread<br>
happens as part of the call_cnt mechanism in the
callback(s).<br>
<br>
Given this, I wanted to know if I would be flouting any of
assumptions, if I used<br>
synctask_yield and synctask_wake as opposed to their macro
counterparts. More specifically,<br>
is there a chance that synctask_get() would return NULL on a
thread which is part of a syncenv's<br>
thread pool?<br>
<br>
thanks,<br>
krish<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>