Re: Lock.lock("info")..

Gregg Wonderly via Concurrency-interest <[email protected]> Mon, 22 Nov 2021 10:22:06 -0600
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <[email protected]>
--===============7672792755892880362==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_084853F4-D863-4FAD-B858-3279C4474C63"


--Apple-Mail=_084853F4-D863-4FAD-B858-3279C4474C63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For me, there is a whole list of =E2=80=9CReporting=E2=80=9D based =
interfaces that I typically use.  These names are an example, but they =
help me separate implementations out so that logging vs console and =
historical data repos etc, can all be inserted into my =E2=80=9CReporting=E2=
=80=9D.

public interface Report {
	String getDetails();
	String getLocation();
	bool hasLocation();
}=09

public interface Reportable {
	Report getReport();
}

public interface Reporter {
	String getName();
	void report( Reportable obj );
}

public class ReportingManager {
	static ReportingManager getDefault();
	static Iterator<Reporter> getAll();
	static Reporter getReporter( String which );
	static void add( Reporter reporter );
	static void remove( Reporter reporter );
	static void removeAll();
	static void report( Reportable rep );
	static void report( Report rep );
	static void reportTo( String rptr, Reportable rep );
	static void reportTo( String rptr, Report rep );
}

With these kinds of interfaces, logging and all kinds of details get =
abstracted into something that is pluggable and extendable.  Your lock =
holder can be a Reportable for example, so that it can be any object =
your need to report something about.  This kind of API might be =
interesting to the OpenJDK, but is just not something that is explicitly =
about concurrency as Doug indicates.

Gregg Wonderly

> On Nov 22, 2021, at 3:30 AM, Kedar C. Raybagkar via =
Concurrency-interest <[email protected]> wrote:
>=20
> Yes, that was the holder that I was referring to.
>=20
> I understand that Lock is not a repo but a small String that captures =
the reason for acquiring the lock would have helped. I have it already =
addressed; so just wanted to check if there is a possibility to have =
that API so that we don't have to create similar holders that capture =
the reason as the reasons are dynamic in nature.
>=20
> Do appreciate the follow ups! We can close this thread.
>=20
> Thanks & Regards,
> -Kedar.
>=20
> On Mon, 22 Nov 2021 at 14:51, David Holmes <[email protected] =
<mailto:[email protected]>> wrote:
> Hi Kedar,
>=20
> =20
>=20
> I added back the c-I list.
>=20
> =20
>=20
> So IIUC you want to store information about the last operation with =
the lock, so that next time if you can=E2=80=99t get it (?) because =
teardown has not finished, you could query the lock to see what the =
previous operation was, and report that back. In other words your lock =
is the only common object you have for different messages in the same =
session so you want to use it to channel the data through. In such a =
situation I would expect you to map a session id to a Session object =
which includes the lock and any other data about the session you might =
want to track. If that is the =E2=80=9CHolder=E2=80=9D that you =
previously referred to then that is the best way to do this IMO.
>=20
> =20
>=20
> It isn=E2=80=99t the job of a Lock to act as a data repository, so I =
would not consider adding the kind of API you have suggested.
>=20
> =20
>=20
> Cheers,
>=20
> David
>=20
> =20
>=20
> From: Kedar C. Raybagkar <[email protected] =
<mailto:[email protected]>>=20
> Sent: Monday, 22 November 2021 6:18 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [concurrency-interest] Lock.lock("info")..
>=20
> =20
>=20
> Consider a simple servlet.
>=20
> =20
>=20
> This servlet creates an AsyncFuture and waits for say 3 seconds max =
before sending the response out to the caller. If the response is =
generated within 3 seconds it is sent out, else we send a long running =
response (with reference to the future) to the caller. The caller if =
receives the response it displays it else if it finds a long running =
response then again calls the server by passing the reference id.
>=20
> =20
>=20
> Now we have this future execute the job in two distinct ways. #1 waits =
till the entire operation is complete and #2 with no wait for the tear =
down process.
>=20
> =20
>=20
> Teardown process serializes some data and it takes some time before it =
completes but the response is already generated and can be sent to the =
caller.
>=20
> =20
>=20
> In case of #2 what we do is on the queue we push the response early on =
and then continue to do teardown. The caller waits on the queue and as =
soon as the response is received it returns that to the caller.
>=20
> =20
>=20
> Usually the user takes time to send further requests to the server and =
in normal scenarios the tear down is finished by the time the next =
request comes. When the next request comes to the server we have to =
ensure that the prior requests teardown is complete. So we have used =
Lock to latch on and release it once teardown is complete. The latch is =
acquired as per the session (UUID reference) so that when the next =
request comes it gets the same latch and waits on the latch to be =
released.
>=20
> =20
>=20
> As we need to keep all these Locks in a map based on the UUID (session =
identifier) we need to hold on to the encapsulated lock DTO that holds =
the purpose of what was being done before.
>=20
> =20
>=20
> Hope I am able to explain it to your satisfaction.
>=20
> =20
>=20
> Thanks & Regards,
>=20
> =20
>=20
> =20
>=20
> On Mon, 22 Nov 2021 at 12:01, David Holmes <[email protected] =
<mailto:[email protected]>> wrote:
>=20
> Why do you need a Holder object for the lock and condition? The lock =
and condition belong in the object whose state they are guarding and =
interacting with. If you are using external synchronization you wont =
have an encapsulated lock/condition but the code using the =
lock/condition has to know what it is actually dealing with and so that =
code can report that information.
>=20
> =20
>=20
> David
>=20
> =20
>=20
> From: Kedar C. Raybagkar <[email protected] =
<mailto:[email protected]>>=20
> Sent: Monday, 22 November 2021 4:23 PM
> To: [email protected] <mailto:[email protected]>
> Cc: [email protected] =
<mailto:[email protected]>
> Subject: Re: [concurrency-interest] Lock.lock("info")..
>=20
> =20
>=20
> Thank you, David.
>=20
> =20
>=20
> That is what I have been doing but instead of having to encapsulate =
into a separate holder object I thought it might be a good idea to have =
some API directly available. As encapsulation also results in having a =
Value Object with hashcode and equals being overridden and then keeping =
them in a map with thread ids. This is already within the lock; just an =
additional string or object parameter may help solve the problem.
>=20
> =20
>=20
> Regards,
>=20
> -Kedar.
>=20
> =20
>=20
> On Mon, 22 Nov 2021 at 11:28, David Holmes <[email protected] =
<mailto:[email protected]>> wrote:
>=20
> Hi Kedar,
>=20
> =20
>=20
> The Lock and Condition should be encapsulated inside the object that =
needs them, and that object can provide whatever additional information =
the callers needs on its own methods.
>=20
> =20
>=20
> Cheers,
>=20
> David
>=20
> =20
>=20
> From: Concurrency-interest <[email protected] =
<mailto:[email protected]>> On Behalf Of Kedar =
C. Raybagkar via Concurrency-interest
> Sent: Monday, 22 November 2021 3:43 PM
> To: [email protected] =
<mailto:[email protected]>
> Subject: [concurrency-interest] Lock.lock("info")..
>=20
> =20
>=20
> Hi,
>=20
> =20
>=20
> Can we have something API where we can provide why we have acquired a =
lock so that when waiting on a condition if timed out we can fetch the =
info and return it to the caller?
>=20
> =20
>=20
> Regards,
>=20
> -Kedar.
>=20
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--Apple-Mail=_084853F4-D863-4FAD-B858-3279C4474C63
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">For =
me, there is a whole list of =E2=80=9CReporting=E2=80=9D based =
interfaces that I typically use. &nbsp;These names are an example, but =
they help me separate implementations out so that logging vs console and =
historical data repos etc, can all be inserted into my =
=E2=80=9CReporting=E2=80=9D.<div class=3D""><br class=3D""></div><div =
class=3D"">public interface Report {</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>String =
getDetails();</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>String getLocation();</div><div =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>bool hasLocation();</div><div class=3D"">}<span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span></div><div class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">public interface Reportable {</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Report =
getReport();</div><div class=3D"">}</div><div class=3D""><br =
class=3D""></div><div class=3D"">public interface Reporter {</div><div =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>String getName();</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>void =
report( Reportable obj );</div><div class=3D"">}</div><div class=3D""><br =
class=3D""></div><div class=3D"">public class ReportingManager =
{</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static ReportingManager =
getDefault();</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>static Iterator&lt;Reporter&gt; =
getAll();</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>static Reporter getReporter( =
String which );</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>static void add( Reporter =
reporter );</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static void remove( Reporter =
reporter );</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static void =
removeAll();</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static void report( Reportable =
rep );</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static void report( Report rep =
);</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>static void reportTo( String =
rptr, Reportable rep );</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>static =
void reportTo( String rptr, Report rep );</div><div class=3D"">}<br =
class=3D""><div><br class=3D""></div><div>With these kinds of =
interfaces, logging and all kinds of details get abstracted into =
something that is pluggable and extendable. &nbsp;Your lock holder can =
be a Reportable for example, so that it can be any object your need to =
report something about. &nbsp;This kind of API might be interesting to =
the OpenJDK, but is just not something that is explicitly about =
concurrency as Doug indicates.</div><div><br class=3D""></div><div>Gregg =
Wonderly</div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Nov 22, 2021, at 3:30 AM, Kedar C. =
Raybagkar via Concurrency-interest &lt;<a =
href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">Yes, that was the holder that I was referring to.<div =
class=3D""><br class=3D""><div class=3D"">I understand that Lock is not =
a repo but a small String that captures the reason for acquiring the =
lock would have helped. I have it already addressed; so just wanted to =
check if there is a possibility&nbsp;to have that API so that we don't =
have&nbsp;to create similar holders that capture the reason as the =
reasons are dynamic in nature.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Do appreciate the follow ups! We can =
close this thread.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks &amp;&nbsp;Regards,</div><div =
class=3D"">-Kedar.</div></div></div><br class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 22 =
Nov 2021 at 14:51, David Holmes &lt;<a =
href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div lang=3D"EN-AU" =
style=3D"overflow-wrap: break-word;" class=3D""><div =
class=3D"gmail-m_9202285258186441888WordSection1"><p =
class=3D"MsoNormal"><span class=3D"">Hi Kedar,<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span class=3D""><u =
class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span class=3D"">I added back the c-I list.<u =
class=3D""></u><u class=3D""></u></span></p><p class=3D"MsoNormal"><span =
class=3D""><u class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span class=3D"">So IIUC you want to store =
information about the last operation with the lock, so that next time if =
you can=E2=80=99t get it (?) because teardown has not finished, you =
could query the lock to see what the previous operation was, and report =
that back. In other words your lock is the only common object you have =
for different messages in the same session so you want to use it to =
channel the data through. In such a situation I would expect you to map =
a session id to a Session object which includes the lock and any other =
data about the session you might want to track. If that is the =
=E2=80=9CHolder=E2=80=9D that you previously referred to then that is =
the best way to do this IMO.<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span class=3D""><u =
class=3D""></u>&nbsp;<u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span class=3D"">It isn=E2=80=99t the job of a Lock =
to act as a data repository, so I would not consider adding the kind of =
API you have suggested.<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span class=3D""><u class=3D""></u>&nbsp;<u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span =
class=3D"">Cheers,<u class=3D""></u><u class=3D""></u></span></p><p =
class=3D"MsoNormal"><span class=3D"">David<u class=3D""></u><u =
class=3D""></u></span></p><p class=3D"MsoNormal"><span class=3D""><u =
class=3D""></u>&nbsp;<u class=3D""></u></span></p><div =
style=3D"border-right:none;border-bottom:none;border-left:none;border-top:=
1pt solid rgb(225,225,225);padding:3pt 0cm 0cm" class=3D""><p =
class=3D"MsoNormal"><b class=3D""><span lang=3D"EN-US" =
class=3D"">From:</span></b><span lang=3D"EN-US" class=3D""> Kedar C. =
Raybagkar &lt;<a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a>&gt; <br =
class=3D""><b class=3D"">Sent:</b> Monday, 22 November 2021 6:18 PM<br =
class=3D""><b class=3D"">To:</b> <a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a><br class=3D""><b =
class=3D"">Subject:</b> Re: [concurrency-interest] Lock.lock("info")..<u =
class=3D""></u><u class=3D""></u></span></p></div><p =
class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u class=3D""></u></p><div =
class=3D""><p class=3D"MsoNormal">Consider a simple servlet.<u =
class=3D""></u><u class=3D""></u></p><div class=3D""><p =
class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">This =
servlet creates an AsyncFuture and waits for say 3 seconds max before =
sending the response out to the caller. If the response is generated =
within 3 seconds it is sent out, else we send a long running response =
(with reference to the future) to the caller. The caller if receives the =
response it displays it else if it finds a long running response then =
again calls the server by passing the reference id.<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">Now we have this future execute the job in two =
distinct ways. #1 waits till the entire operation is complete and #2 =
with no wait for the tear down process.<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">Teardown process serializes some data and it takes =
some&nbsp;time before it completes but the response is already generated =
and can be sent to the caller.<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">In case of #2 what we do is on the queue we push the =
response early on and then continue to do teardown. The caller waits on =
the queue and as soon as the response&nbsp;is received&nbsp;it returns =
that to the caller.<u class=3D""></u><u class=3D""></u></p></div><div =
class=3D""><p class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">Usually =
the user takes time to send further requests to the server and in normal =
scenarios the tear down is finished by the time the next request comes. =
When the next request comes to the server we have to ensure that the =
prior requests teardown is complete. So we have used Lock to latch on =
and release it once teardown is complete. The latch is acquired as per =
the session (UUID reference) so that when the next request comes it gets =
the same latch and waits on the latch to be released.<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">As we need to keep all these Locks in a map based on =
the UUID (session identifier) we need to hold on to the encapsulated =
lock DTO that holds the purpose of what was being done before.<u =
class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">Hope I =
am able to explain it to your satisfaction.<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">Thanks &amp; Regards,<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u =
class=3D""></u>&nbsp;<u class=3D""></u></p></div></div><p =
class=3D"MsoNormal"><u class=3D""></u>&nbsp;<u class=3D""></u></p><div =
class=3D""><div class=3D""><p class=3D"MsoNormal">On Mon, 22 Nov 2021 at =
12:01, David Holmes &lt;<a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a>&gt; wrote:<u =
class=3D""></u><u class=3D""></u></p></div><blockquote =
style=3D"border-top:none;border-right:none;border-bottom:none;border-left:=
1pt solid rgb(204,204,204);padding:0cm 0cm 0cm =
6pt;margin-left:4.8pt;margin-right:0cm" class=3D""><div class=3D""><div =
class=3D""><p class=3D"MsoNormal">Why do you need a Holder object for =
the lock and condition? The lock and condition belong in the object =
whose state they are guarding and interacting with. If you are using =
external synchronization you wont have an encapsulated lock/condition =
but the code using the lock/condition has to know what it is actually =
dealing with and so that code can report that information.<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">David<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p><div =
style=3D"border-right:none;border-bottom:none;border-left:none;border-top:=
1pt solid rgb(225,225,225);padding:3pt 0cm 0cm" class=3D""><p =
class=3D"MsoNormal"><b class=3D""><span lang=3D"EN-US" =
class=3D"">From:</span></b><span lang=3D"EN-US" class=3D""> Kedar C. =
Raybagkar &lt;<a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a>&gt; <br =
class=3D""><b class=3D"">Sent:</b> Monday, 22 November 2021 4:23 PM<br =
class=3D""><b class=3D"">To:</b> <a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a><br class=3D""><b =
class=3D"">Cc:</b> <a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a><br =
class=3D""><b class=3D"">Subject:</b> Re: [concurrency-interest] =
Lock.lock("info")..</span><u class=3D""></u><u class=3D""></u></p></div><p=
 class=3D"MsoNormal">&nbsp;<u class=3D""></u><u class=3D""></u></p><div =
class=3D""><div class=3D""><p class=3D"MsoNormal">Thank you, David.<u =
class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">That is =
what I have been doing but instead of having to encapsulate&nbsp;into a =
separate holder object I thought it might be a good idea to have some =
API directly available. As encapsulation&nbsp;also results in having a =
Value Object with hashcode and equals being overridden and then keeping =
them in a map with thread ids. This is already within the lock; just an =
additional string or object parameter may help solve the&nbsp;problem.<u =
class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">Regards,<u=
 class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">-Kedar.<u class=3D""></u><u =
class=3D""></u></p></div></div><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p><div class=3D""><div class=3D""><p =
class=3D"MsoNormal">On Mon, 22 Nov 2021 at 11:28, David Holmes &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>&gt; wrote:<u class=3D""></u><u =
class=3D""></u></p></div><blockquote =
style=3D"border-top:none;border-right:none;border-bottom:none;border-left:=
1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm 5pt =
4.8pt" class=3D""><div class=3D""><div class=3D""><p =
class=3D"MsoNormal">Hi Kedar,<u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal">&nbsp;<u class=3D""></u><u class=3D""></u></p><p =
class=3D"MsoNormal">The Lock and Condition should be encapsulated inside =
the object that needs them, and that object can provide whatever =
additional information the callers needs on its own methods.<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">Cheers,<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">David<u =
class=3D""></u><u class=3D""></u></p><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p><div =
style=3D"border-right:none;border-bottom:none;border-left:none;border-top:=
1pt solid rgb(225,225,225);padding:3pt 0cm 0cm" class=3D""><p =
class=3D"MsoNormal"><b class=3D""><span lang=3D"EN-US" =
class=3D"">From:</span></b><span lang=3D"EN-US" class=3D""> =
Concurrency-interest &lt;<a =
href=3D"mailto:[email protected]" =
target=3D"_blank" =
class=3D"">[email protected]</a>&gt; <b =
class=3D"">On Behalf Of </b>Kedar C. Raybagkar via =
Concurrency-interest<br class=3D""><b class=3D"">Sent:</b> Monday, 22 =
November 2021 3:43 PM<br class=3D""><b class=3D"">To:</b> <a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a><br class=3D""><b =
class=3D"">Subject:</b> [concurrency-interest] =
Lock.lock("info")..</span><u class=3D""></u><u class=3D""></u></p></div><p=
 class=3D"MsoNormal">&nbsp;<u class=3D""></u><u class=3D""></u></p><div =
class=3D""><p class=3D"MsoNormal">Hi,<u class=3D""></u><u =
class=3D""></u></p><div class=3D""><p class=3D"MsoNormal">&nbsp;<u =
class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">Can we have something API where we can provide why =
we have acquired a lock so that when waiting on a condition if timed =
out&nbsp;we can fetch the info and return it to the caller?<u =
class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">&nbsp;<u class=3D""></u><u =
class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">Regards,<u=
 class=3D""></u><u class=3D""></u></p></div><div class=3D""><p =
class=3D"MsoNormal">-Kedar.<u class=3D""></u><u =
class=3D""></u></p></div></div></div></div></blockquote></div></div></div>=
</blockquote></div></div></div></blockquote></div>
_______________________________________________<br =
class=3D"">Concurrency-interest mailing list<br class=3D""><a =
href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a><br =
class=3D"">http://cs.oswego.edu/mailman/listinfo/concurrency-interest<br =
class=3D""></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_084853F4-D863-4FAD-B858-3279C4474C63--

--===============7672792755892880362==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--===============7672792755892880362==--