- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > btw I have this growing suspicion that we should eliminate > Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores > on their own should *not* provide a facility for to protect critical > regions since they suffer from accidental release [1] due to > *lack*of*ownership*. > I have same feeling when analyse problem of critical: implementation. But I not think that Semaphore>>forMutualExclusion is bad. It is common case that semaphore "free" by default. And this name is explicitly said about this.

Jan. 5, 2016

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Esteban Lorenzano

> On 05 Jan 2016, at 16:51, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 05-01-16 16:21, Esteban Lorenzano wrote: >> Soâ¦ I took a couple of minutes to do a small list of project description status: >> >> From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. >> Which means 264 are mysterious projects nobody can guess what are they about. >> >> I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) >> Even very important projects like Seaside or Garage and Glorp are not documented. >> >> So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. >> >> Here the list of non-documented projects: > > ss3 has no projects? catalog just catalogs projects in the MetaRepos you project can live where he wants, but configuration needs to be copied into MetaRepoForPharoXX thatâs how always was, and thatâs what catalog shows :) Esteban > > Stephan > > >

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

Hi Thank you very much for this analysts. 2016-01-05 16:06 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > This is really strange! Why does the copied class Semaphore2 behave > differently to the original class Semaphore? This was in build 50510. > It is so frustrating. I add tests for your cases which is red now. And one for Semaphore (inside ReadWriteLockTests) which is green

Jan. 5, 2016

Re: [Pharo-dev] Catalog statistics (Who know this projects?)

by Stephan Eggermont

On 05-01-16 16:21, Esteban Lorenzano wrote: > Soâ¦ I took a couple of minutes to do a small list of project description status: > > From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. > Which means 264 are mysterious projects nobody can guess what are they about. > > I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) > Even very important projects like Seaside or Garage and Glorp are not documented. > > So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. > > Here the list of non-documented projects: ss3 has no projects? Stephan

Jan. 5, 2016

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Sven Van Caekenberghe

Cool. I just merged it and I can confirm that it solves my issue. > On 05 Jan 2016, at 16:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > yes, > > this is fixed by > > https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring > > I am now back from holidays and will review/intergrate this soon. > > >> On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I am seeing the following very annoying error in 50511 spur. >> >> Open a Playground, >> type [ (both open en close are inserted, with the cursor in-between), >> type : (to start a block arg), >> boom: >> >> RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance >> OCASTClosureAnalyzer>>changeVariableClass: >> OCASTClosureAnalyzer>>visitArgumentNode: >> [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OCASTClosureAnalyzer>>visitBlockNode: >> RBBlockNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> RBSequenceNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTClosureAnalyzer>>visitMethodNode: >> RBMethodNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>analyze: >> RBMethodNode>>doSemanticAnalysis >> RBBlockNode(RBProgramNode)>>doSemanticAnalysis >> RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: >> [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] >> forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess >> >> Has this already been reported ? >> >> It makes the image almost unusable... >> >> Sven >> >> > >

Jan. 5, 2016

Catalog statistics (Who know this projects?)

by Esteban Lorenzano

Soâ¦ I took a couple of minutes to do a small list of project description status: >From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. Which means 264 are mysterious projects nobody can guess what are they about. I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) Even very important projects like Seaside or Garage and Glorp are not documented. So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. Here the list of non-documented projects: http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main --- 'A4BP' 'Aconcagua' 'BootstrapMagritte' 'Chalten' 'CommandShell' 'Cormas' 'DependencyAnalyser' 'FamixJS' 'FontAwesome' 'Garage' 'GarageConnectionPool' 'GarageGlorp' 'Glorp' 'Grease' 'IniModules' 'Kendrick' 'Magritte3' 'MagritteMagic' 'MetaBoardBoard' 'MyFirstWebApp' 'NBOpenGL' 'NeoJSON' 'OSProcess' 'PetitParser' 'Phexample' 'Pier3' 'Pier3AddOns' 'ProcessWrapper' 'RewriteTool' 'Seaside3' 'SimplePersistence' 'Ston' 'Telescope' 'Woden' âXtreams' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main --- 'AconcaguaDeluxe' 'AthensSVG' 'Autotest' 'CPanel' 'CreativeCommonsLive' 'DevFlow' 'EventRecorder' 'ExtendedNumberParser' 'ExternalWebBrowser2' 'FixedDecimal' 'Ghost' 'GraphViz' 'Gravatar' 'Hubcap' 'Infinity' 'Mandrill' 'Mathex' 'MemoryMonitor' 'MinimalConnectors' 'Mocketry' 'MongoTalk' 'NBSQLite3' 'NumericalMethods' 'ODBC' 'OSOSX' 'OSWindows' 'PackageDependenciesAnalysis' 'PharoLauncher' 'PlagueDoctor' 'Pomodoro' 'RemoteAnnouncement' 'SandstoneDb' 'Scheduler' 'ScriptManager' 'Shapes' 'SmallUML' 'Spreadsheet' 'Spy' 'StateSpecs' 'SuffixConditionals' 'Teachable' 'TestMock' 'Trees' 'Twilio' 'Vidi' 'VistaCursors' 'Viva' 'WiringPi' 'WorkingSet' 'XBase' 'sQuick' âsQuick_new' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main --- 'Actalk' 'Arduino' 'BabyMock2' 'CTranslator' 'DBPedia' 'DigitalOcean' 'Forum' 'Fuel' 'GTDebugger' 'GTInspector' 'GTInspectorCore' 'GTPlayground' 'GTPlaygroundCore' 'GTSpotter' 'GToolkit' 'GlamourCore' 'GlorpDBX' 'GraphET' 'InstanceEncoder' 'Marina' 'Mechanize' 'Memcached' 'Moose' 'Pastell' 'PharoOnlineHelp' 'ProfStef' 'PythonParser' 'RFB' 'Roassal3d' 'SQLite3' 'Smallapack' 'SmalltalkHub' 'Snapshotcello' 'SortFunctions' 'Spotlight' 'Stamp' 'Tide' 'VersionBrowser' âVersionner' http://www.squeaksource.com/MetacelloRepository --- 'AXAnnouncements' 'Adore' 'Aida' 'Ajp' 'Algernon' 'Alien' 'Amers' 'Announcements' 'AutomaticMethodCategorizer' 'BetaNineIPAddress' 'CAnalyzer' 'CairoGraphics' 'CampSmalltalkLondon' 'Cecinestpasunepomme' 'CharacterMap' 'Chronos' 'CloudforkAWS' 'Cog' 'Connectors' 'ContextS' 'Control' 'Country' 'Countryside' 'DBXBrowser' 'DBXTools' 'DependencyBrowser' 'DependencyView' 'EnhancedOmniBrowser' 'ExternalIconFamily' 'ExternalWebBrowser' 'FileMan' 'FileTree' 'Filesystem' 'GemTools' 'Gitocello' 'Glamour' 'Gofer' 'GoferProjectLoader' 'GoogleAnalytics' 'HPDF' 'HealthReportProducer' 'HelpSystem' 'ICal' 'InstancesBrowser' 'JQueryWidgetBox' 'JavaScriptAnalyzer' 'Jejak' 'Keymapping' 'Kozen' 'KyotoTycoonClient' 'MaBase' 'MaClientServer' 'Magma' 'Magmafy' 'Magritte' 'Magritte2' 'Magritte3AddOns' 'MagritteAddOns2' 'Metacello' 'MetacelloBrowser' 'MetacelloPreview' 'MockGemStone' 'Mondrian' 'Money' 'MonticelloRedirect' 'Murmansk' 'Nagare' 'NativeBoost' 'Neo4reSt' 'NewECompletion' 'NewInspector' 'NewOCompletion' 'Nile' 'NotificationsArea' 'O2' 'OCompletion' 'OPAX' 'ObjectMetaTools' 'OmniBrowser' 'OmniBrowserLukas' 'Orca' 'PagedReader' 'Pharo' 'PharoMorphicExtras' 'PharoNonCore' 'Phriak' 'Pier' 'Pier2' 'PierAddOns' 'PierAddOns2' 'PostMark' 'ProcessModel' 'Quaternion' 'REPL' 'Raphael' 'RatPack' 'RefactoringBrowser' 'RefactoringTools' 'RoelTyper' 'SIXX' 'SPort2' 'SandcastleThemes' 'Scamper' 'Scribo' 'Seafox' 'Seaside' 'Seaside28' 'Seaside28Examples' 'Seaside30' 'SeasideJSON' 'SeasideRest' 'SeasideTesting' 'SharedWorkspace' 'Shout' 'SimpleApplescript' 'SoapOpera' 'SpellingServices' 'SpyForO2' 'Sqnappy' 'SqueakCheck' 'SqueakDBX' 'SqueakFS' 'SqueakSource' 'StOMP' 'Stripe' 'SunnysidePlanning2' 'SwaLint' 'Swazoo2' 'TODO' 'TimerDaemon' 'Tuio' 'VMMaker' 'Waterfall' 'WebClient' 'WebTester' 'XMLRPC' 'XMLSupport' 'Zodiac'

Jan. 5, 2016

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Marcus Denker

yes, this is fixed by https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring I am now back from holidays and will review/intergrate this soon. > On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I am seeing the following very annoying error in 50511 spur. > > Open a Playground, > type [ (both open en close are inserted, with the cursor in-between), > type : (to start a block arg), > boom: > > RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance > OCASTClosureAnalyzer>>changeVariableClass: > OCASTClosureAnalyzer>>visitArgumentNode: > [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: > OrderedCollection>>do: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: > OCASTClosureAnalyzer>>visitBlockNode: > RBBlockNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: > OrderedCollection>>do: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: > RBSequenceNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTClosureAnalyzer>>visitMethodNode: > RBMethodNode>>acceptVisitor: > OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>analyze: > RBMethodNode>>doSemanticAnalysis > RBBlockNode(RBProgramNode)>>doSemanticAnalysis > RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: > [ self privateStyle: text. > view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. > view ifNotNil: [ view stylerStyledInBackground: text ] ] > forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess > > Has this already been reported ? > > It makes the image almost unusable... > > Sven > >

Jan. 5, 2016

Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Sven Van Caekenberghe

I am seeing the following very annoying error in 50511 spur. Open a Playground, type [ (both open en close are inserted, with the cursor in-between), type : (to start a block arg), boom: RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance OCASTClosureAnalyzer>>changeVariableClass: OCASTClosureAnalyzer>>visitArgumentNode: [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: OrderedCollection>>do: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: OCASTClosureAnalyzer>>visitBlockNode: RBBlockNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: OrderedCollection>>do: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: RBSequenceNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTClosureAnalyzer>>visitMethodNode: RBMethodNode>>acceptVisitor: OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTSemanticAnalyzer>>analyze: RBMethodNode>>doSemanticAnalysis RBBlockNode(RBProgramNode)>>doSemanticAnalysis RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. view ifNotNil: [ view stylerStyledInBackground: text ] ] forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: [ self value. Processor terminateActive ] in BlockClosure>>newProcess Has this already been reported ? It makes the image almost unusable... Sven

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

On Tue, Jan 5, 2016 at 1:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > configurationOf: 'ReadWriteLock'; > loadStable > > > It is reentral read write lock which described in > https://en.wikipedia.org/wiki/Readersâwriter_lock. From the article: > >> An ReadWriteLock allows concurrent access for read-only operations, while >> write operations require exclusive access. This means that multiple threads >> can read the data in parallel but an exclusive lock is needed for writing or >> modifying data. When a writer is writing the data, all other writers or >> readers will be blocked until the writer is finished writing. > > > Public API and Key Messages > > - lock := ReadWriteLock new > - lock criticalRead: aBlock > - lock criticalWrite: aBlock > > Implementation based on two semaphores and readers counter. > > Main difficulty is carefully handle process termination during execution of > critical sections. This problem described in Semaphore>>critical: comment. > Same approach is used here. But synchronisation logic around two semaphores > for reading and writing complicates things very much. No simple way to > decompose logic on multiple methods because information about process > interruption become hidden. > From the Semaphore comment: >> >> The main trick is assignment right before we go into the wait primitive >> (which is not a real send and therefore not interruptable either). So after >> we can check that waiting is happen or not. > > > Tests are implemented only for lock scenarios. No tests for described > termination process cases. It is not really clear how to write it. > I will be appreciate if people review code. Maybe you will suggest > simplifications. It is always difficult to implement concurrent code. > > Best regards, > Denis I don't think /writeIsLocked/ is a good variable name in #criticalWrite: . Even though its a local var, its semantic "feels" object wide. Consider process A enters #criticalWrite and gains the write lock, then process B enters #criticalWrite: where it does "writeIsLocked := false" -- but A still has the lock, so the semantic is confusing. Perhaps renaming to something like "ensureRelease" is more intention revealing. waiting inside the ensure-main-block is interrupted. If B is terminated, then the ensure-block executes Now there is a problem with the logic of #criticalWrite: Consider a scenario where process p1 is holding the writersSemaphore for a long time, and processes p2 and p3 are waiting on it. If p2 is terminated, then its ensure-block executes, which signals writersSemaphore and p3 proceeds prematurely. By way of example, try this... | lock p1 p2 p3| Transcript clear. lock := ReadWriteLock new. p1 := [ Transcript crShow: '1A'. lock criticalWrite: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock criticalWrite: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock criticalWrite: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. " (1 second wait). p2 terminate. " ...with the last two lines commented, you get the expected result... A1 A2 B1 C1 "Correctly pauses until <Proceed> debugger" B2 C2 ..but if you uncomment the last two lines you get... 1A 1B 2A 3A "whoops, did not pause here until <Proceed> in debugger" 3B You can observe this further by adding the following logging to the top of the ensure block... ] ensure: [ Transcript crShow: writersSemaphore excessSignals ; tab ; show: activeProcess == writeLockOwner ; tab ; show: aBlock. ... So when p2 is terminated, it is no longer waiting on /writersSemaphore/ and thus will not be consuming a signal, so we should avoid signalling it when the process it terminated. One solution might be... criticalWrite: aBlock | activeProcess ensureRelease blockResult| activeProcess := Processor activeProcess. activeProcess == writeLockOwner ifTrue:[ ^aBlock value]. ensureRelease := false. blockResult := [ ensureRelease := true. writersSemaphore wait. writeLockOwner := activeProcess. aBlock value ] ensure: [ "Need to avoid signalling when terminated, since it never consumed a signal" (ensureRelease and: [ activeProcess == writeLockOwner ]) ifTrue: [ writeLockOwner := nil. writersSemaphore signal ]. ]. ^ blockResult Now I was curious why Semaphore>>critical: did not exhibit the same problem, since the following... | lock p1 p2 p3| Transcript clear. lock := Semaphore forMutualExclusion. p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. (1 second wait). p2 terminate. which produces... 1A 1B 2A 3A "Correctly pauses until <Proceed> debugger" 3B However, if I copy Semaphore to Semaphore2 and do this... | lock p1 p2 p3| Transcript clear. lock := Semaphore2 forMutualExclusion. p1 := [ Transcript crShow: '1A'. lock critical: [ Transcript crShow: '1B'. self halt ] ] newProcess name: 'LOCK1' . p2 := [ Transcript crShow: '2A'. lock critical: [ Transcript crShow: '2B' ] ] newProcess name: 'LOCK2' . p3 := [ Transcript crShow: '3A'. lock critical: [ Transcript crShow: '3B' ] ] newProcess name: 'LOCK3' . p1 resume. p2 resume. p3 resume. (1 second wait). p2 terminate. it produces... 1A 1B 2A 3A "whoops, did not pause here until <Proceed> in debugger" 3B This is really strange! Why does the copied class Semaphore2 behave differently to the original class Semaphore? This was in build 50510. btw I have this growing suspicion that we should eliminate Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores on their own should *not* provide a facility for to protect critical regions since they suffer from accidental release [1] due to *lack*of*ownership*. This is the root cause of the problem scenario above. Mutex>>critical: which does have a sense of ownership should be used instead. Indeed, [2] advises "The correct use of a semaphore is for *signaling* from one task to another. A mutex is meant to be taken and released, always in that order, by *[the same]* task that uses the shared resource it protects." -- But this is a subtle distinction and having Semaphore>>critical: leads people to incorrect thinking and exposes them to subtle errors. Mutex>>critical: cold still be implemented using Semaphore, but rather than just forwarding to Semaphore>>critical: pull that method's code out into Mutex>>critical: so it looks like what Denis did for #criticalWrite: Or alternatives, we should consider directly using the mutex primitives Eliot mentioned some time ago were already in the VM. [1] https://blog.feabhas.com/2009/09/mutex-vs-semaphores-%E2%80%93-part-1-semap… [2] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore cheers -ben

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Denis Kudriashov

:) 5 ÑÐ½Ð². 2016 Ð³. 2:18 PM Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Max Leske" <maxleske(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > On 05 Jan 2016, at 13:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> What I donât quite understand is why Monitor doesnât use >> Semaphore>>critical:. If it did that, then there wouldnât be a problem. The >> problem only exists because #wait and #signal are explicitly sent by the >> monitor. > > > Monitor is reentral which means that two recursive critical sections in > same process should not be blocked. This logic implemented in #enter and > #exit methods > > > I should start using my head again. This is a new yearâ¦ :) > > Thanks Denis. > >

Jan. 5, 2016