Re: Lock.lock("info")..
Gregg Wonderly via Concurrency-interest <[email protected]> Mon, 22 Nov 2021 17:04:13 -0600
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <[email protected]> |
--===============1338481262036865353== Content-Type: multipart/alternative; boundary="Apple-Mail=_5891E1DB-B1B0-400F-8A3D-0D86D558E3E0" --Apple-Mail=_5891E1DB-B1B0-400F-8A3D-0D86D558E3E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can use a Logger behind Reporter for sure. The detail is that I = also want to have a remote Handler that I can tap into and watch = what=E2=80=99s happening and manipulate the levels of the loggers from = that interface. But, java.util.logging=E2=80=99s Level in Logger = instances is not associated with the tie into the handler. What I = typically need, is for a Logger=E2=80=99s level to actually be a guard = that the Handler level checks. Thus instead of all Handler=E2=80=99s = being filtered by the Logger level, I want each Handler to have a level = for each Logger so that I can filter Loggers by Handler, instead of just = at the Logger level. Yes, you can use the Handler level to filter = things toward that logger, but that doesn=E2=80=99t allow individual = remote management instances to turn on and off logging levels that they = need for their specific observations in a larger domain of Logger use. Gregg Wonderly > On Nov 22, 2021, at 2:06 PM, Nathan Reynolds <[email protected]> = wrote: >=20 > Why not create a logger that holds some number of debug log messages = in memory for each thread until a warning or error is logged? When a = warning or error is logged, then the logger writes all the messages = regardless of the log level. Hence, the code does debug logging calls = and the logger takes care of the rest. >=20 > In the case of locks, change to a try lock with a timeout. When the = timeout happens, log an error. The logger does the rest. I find this = to be very helpful since the debug log messages can be captured from = ancestor and preceding sibling methods. This way I get much more = contextual information than what can be captured right before attempting = to acquire the lock. >=20 > On Mon, Nov 22, 2021 at 9:23 AM Gregg Wonderly via = Concurrency-interest <[email protected] = <mailto:[email protected]>> wrote: > 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. >=20 > public interface Report { > String getDetails(); > String getLocation(); > bool hasLocation(); > }=09 >=20 > public interface Reportable { > Report getReport(); > } >=20 > public interface Reporter { > String getName(); > void report( Reportable obj ); > } >=20 > 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 ); > } >=20 > 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. >=20 > Gregg Wonderly >=20 >> On Nov 22, 2021, at 3:30 AM, Kedar C. Raybagkar via = Concurrency-interest <[email protected] = <mailto:[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] = <mailto:[email protected]> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest = <http://cs.oswego.edu/mailman/listinfo/concurrency-interest> >=20 > _______________________________________________ > Concurrency-interest mailing list > [email protected] = <mailto:[email protected]> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest = <http://cs.oswego.edu/mailman/listinfo/concurrency-interest> --Apple-Mail=_5891E1DB-B1B0-400F-8A3D-0D86D558E3E0 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"">You = can use a Logger behind Reporter for sure. The detail is that I = also want to have a remote Handler that I can tap into and watch = what=E2=80=99s happening and manipulate the levels of the loggers from = that interface. But, java.util.logging=E2=80=99s Level in Logger = instances is not associated with the tie into the handler. What I = typically need, is for a Logger=E2=80=99s level to actually be a guard = that the Handler level checks. Thus instead of all Handler=E2=80=99s= being filtered by the Logger level, I want each Handler to have a level = for each Logger so that I can filter Loggers by Handler, instead of just = at the Logger level. Yes, you can use the Handler level to filter = things toward that logger, but that doesn=E2=80=99t allow individual = remote management instances to turn on and off logging levels that they = need for their specific observations in a larger domain of Logger = use.<div class=3D""><br class=3D""></div><div class=3D"">Gregg = Wonderly<br class=3D""><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D"">On Nov 22, 2021, at 2:06 PM, Nathan Reynolds = <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"">Why not create a logger that holds some = number of debug log messages in memory for each thread until a warning = or error is logged? When a warning or error is logged, then the = logger writes all the messages regardless of the log level. Hence, = the code does debug logging calls and the logger takes care of the = rest.</div><div class=3D""><br class=3D""></div><div class=3D""> In the = case of locks, change to a try lock with a timeout. When the = timeout happens, log an error. The logger does the rest. I = find this to be very helpful since the debug log messages can be = captured from ancestor and preceding sibling methods. This way I = get much more contextual information than what can be captured right = before attempting to acquire the lock.</div></div><br class=3D""><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov = 22, 2021 at 9:23 AM Gregg Wonderly via Concurrency-interest <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> 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 style=3D"overflow-wrap: = break-word;" class=3D"">For me, there is a whole list of =E2=80=9CReportin= g=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.<div class=3D""><br = class=3D""></div><div class=3D"">public interface Report {</div><div = class=3D""><span style=3D"white-space:pre-wrap" class=3D""> = </span>String getDetails();</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>String = getLocation();</div><div class=3D""><span style=3D"white-space:pre-wrap" = class=3D""> </span>bool hasLocation();</div><div class=3D"">}<span = style=3D"white-space:pre-wrap" class=3D""> </span></div><div = class=3D""><div class=3D""><br class=3D""></div><div class=3D"">public = interface Reportable {</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </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 style=3D"white-space:pre-wrap" class=3D""> = </span>String getName();</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </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 style=3D"white-space:pre-wrap" class=3D""> = </span>static ReportingManager getDefault();</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static = Iterator<Reporter> getAll();</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static Reporter = getReporter( String which );</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static void add( = Reporter reporter );</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static void = remove( Reporter reporter );</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static void = removeAll();</div><div class=3D""><span style=3D"white-space:pre-wrap" = class=3D""> </span>static void report( Reportable rep );</div><div = class=3D""><span style=3D"white-space:pre-wrap" class=3D""> = </span>static void report( Report rep );</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static void = reportTo( String rptr, Reportable rep );</div><div class=3D""><span = style=3D"white-space:pre-wrap" class=3D""> </span>static void = reportTo( String rptr, Report rep );</div><div class=3D"">}<br = class=3D""><div class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br = class=3D""></div><div class=3D"">Gregg Wonderly</div><div class=3D""><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 <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D""><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 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.</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 = & 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 <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> 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" class=3D""><div = class=3D""><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> <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> <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> <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> <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> <u class=3D""></u></span></p><div = style=3D"border-color:rgb(225,225,225) currentcolor = currentcolor;border-style:solid none none;border-width:1pt medium = medium;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 <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> <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> <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> <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> <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> <u = class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal">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.<u class=3D""></u><u class=3D""></u></p></div><div class=3D""><p = class=3D"MsoNormal"><u class=3D""></u> <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 is received 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> <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> <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> <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> <u class=3D""></u></p></div><div class=3D""><p = class=3D"MsoNormal">Thanks & Regards,<u class=3D""></u><u = class=3D""></u></p></div><div class=3D""><p class=3D"MsoNormal"><u = class=3D""></u> <u class=3D""></u></p></div></div><p = class=3D"MsoNormal"><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 = 12:01, David Holmes <<a href=3D"mailto:[email protected]" = target=3D"_blank" class=3D"">[email protected]</a>> wrote:<u = class=3D""></u><u class=3D""></u></p></div><blockquote = style=3D"border-color:currentcolor currentcolor currentcolor = rgb(204,204,204);border-style:none none none solid;border-width:medium = medium medium 1pt;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"> <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"> <u = class=3D""></u><u class=3D""></u></p><div = style=3D"border-color:rgb(225,225,225) currentcolor = currentcolor;border-style:solid none none;border-width:1pt medium = medium;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 <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> <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"> <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"> <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 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.<u = class=3D""></u><u class=3D""></u></p></div><div class=3D""><p = class=3D"MsoNormal"> <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"> <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 <<a = href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a>> wrote:<u class=3D""></u><u = class=3D""></u></p></div><blockquote style=3D"border-color:currentcolor = currentcolor currentcolor rgb(204,204,204);border-style:none none none = solid;border-width:medium medium medium 1pt;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"> <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"> <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"> <u class=3D""></u><u class=3D""></u></p><div = style=3D"border-color:rgb(225,225,225) currentcolor = currentcolor;border-style:solid none none;border-width:1pt medium = medium;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 <<a = href=3D"mailto:[email protected]" = target=3D"_blank" = class=3D"">[email protected]</a>> <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"> <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"> <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 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"> <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]" target=3D"_blank" = class=3D"">[email protected]</a><br class=3D""><a = href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" = target=3D"_blank" = class=3D"">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><= br class=3D""></div></blockquote></div><br = class=3D""></div></div></div>_____________________________________________= __<br class=3D""> Concurrency-interest mailing list<br class=3D""> <a href=3D"mailto:[email protected]" target=3D"_blank" = class=3D"">[email protected]</a><br class=3D""> <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><= br class=3D""> </blockquote></div> </div></blockquote></div><br class=3D""></div></body></html>= --Apple-Mail=_5891E1DB-B1B0-400F-8A3D-0D86D558E3E0-- --===============1338481262036865353== 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 --===============1338481262036865353==--