<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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>
<br>
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>
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<br>
<br>
On 02/14/2013 05:23 AM, Anand Avati wrote:<br>
</div>
<blockquote
cite="mid:CAFboF2xCb+-EOD7B5ewBCto09xGpkqX_TSaruvWBdKKLoAgAwQ@mail.gmail.com"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a moz-do-not-send="true"
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>
</body>
</html>