Re: weird block on Get from basic protected bounded buffer with 2 tasks

[George Shapovalov <gshapovalov@gmail.com>]

On Tuesday, December 12, 2017 at 10:16:07 PM UTC+1, Dmitry A. Kazakov wrote:
> On 2017-12-12 20:08, George Shapovalov wrote:
> Then the barrier must be
>     Count = 0 or else (Count < maxCount and then Get'Count = 0)
> BTW, prioritizing is a bad idea. If you enforce entry order you also 

Thank you for the hint on the barriers. Although yes, this was not the intention, I added that 'Count dependency to see if it helps to resolve that "block". The original implementation was plain as in textbook..

Now, I am "happy" to report that the issue got "resolved" - all quoted, because it simply "just started working". The bigger program, not this example. There were no aborts in it and I even tried to run the LogBuffer.getEvent from the main loop.. 
The bigger code was using synchronized interface with a printEvent(logBuf_Int'Class) procedure and then implementing actual buffer as a protected type (overriding Get and Put). That class-wide printEvent was essentially calling Buffer.Get and then Print(record) (plain type, basic IO - the base idea was to decouple logging and IO, so this was just a "smart wrapper"). Like this:
procedure PrintEvent(LI : in out EventLogger_Interface'Class) is
    ev : Event_Rec;
begin
    LI.GetEvent(ev); -- was not returning from this before
    Put_Line("report point");  -- was never called here earlier
    PrintEvent(ev); -- regular procedure on basic record type calling IO
end;

Weird thing, it was blocking with Buffer.printEvent (class-wide wrapper) in main cycle. But then when I replaced it with two explicit calls (Get then Print) it unblocked and started working as expected.. And then I prepared an update of that simplified code, to include this, but it kept working in the sample code even with Buffer.printItem.. So, I went back and changed code back to Buffer.printItem in the main cycle - and it kept working now with the "big code" too! And I just run a diff against last commit that was blocking - and there are absolutely no changes aside few cosmetics!
So, yeah, I am glad of course it works now, but it really seems like "blocking on Tuesdays" issue right now..