Re: [Pharo-dev] [Ann] ReadWriteLock

Thank you Ben for links 2016-01-13 4:31 GMT+01:00 Ben Coman : > These two read together provide a balanced view. > > ReaderWriterLock vs Monitor > http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor > > When to use the ReaderWriterLock >

Re: [Pharo-dev] [Ann] ReadWriteLock

Denis,  yes, I read it, but I could not find answers there.  Ben, thanks! The second article suggests that readers may do blocking operations inside read-critical sections such as IO. If the critical section may block, then I see the advantage. I always thought doing a blocking operation in a

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi Denis, all,  I'm sorry for asking basic questions, but... I thought of this a little and I failed to see the advantage  of using ReadWriteLock over monitor / mutex. What's the goal of ReadWriteLock? I mean - when should I use it rather than  monitor / mutex? What practical advantage would it

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi. I am going to bed now. Do you look at wikipedia link? 12 янв. 2016 г. 11:29 PM пользователь "Jan Vrany" написал: > Hi Denis, all, > > I'm sorry for asking basic questions, but... > > I thought of this a little and I failed to see the advantage > of using ReadWriteLock

Re: [Pharo-dev] [Ann] ReadWriteLock

I publish version based on new LockOwnership class. It requires slice 17373. Now all test are green 2016-01-10 4:55 GMT+01:00 Ben Coman : > On Fri, Jan 8, 2016 at 9:40 PM, Henrik Johansen > wrote: > > Here's an alternative implementation,

Re: [Pharo-dev] [Ann] ReadWriteLock

On Mon, Jan 11, 2016 at 11:37 PM, Denis Kudriashov wrote: > I publish version based on new LockOwnership class. It requires slice 17373. > Now all test are green Thanks. I look forward to taking a look, but its too late to start tonight. I'll check tomorrow. cheers -ben >

Re: [Pharo-dev] [Ann] ReadWriteLock

On Fri, Jan 8, 2016 at 9:40 PM, Henrik Johansen wrote: > Here's an alternative implementation, which, instead of checking for the new > method name, hooks into the existing unwind machinery to execute the > waitIfCurtailed: argument. > Which removes the special case

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 08 Jan 2016, at 3:07 , Denis Kudriashov wrote: > > Yes. When process suspend called during termination process has no more > semaphore as suspendingList Which is why in terminate I do myList := self suspend. So the semaphore *should* still be the suspendingList,

Re: [Pharo-dev] [Ann] ReadWriteLock

Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument.Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if

Re: [Pharo-dev] [Ann] ReadWriteLock

I not understand. Is you code is working for you? This test return nil on my image: sema := Semaphore new. p:= [ sema waitIfCurtailed: [ r := p suspendingList ] ] fork. 1 seconds wait. p terminate2. "your implementation" r. And what I try to said is as soon as suspend called on waiting process

Re: [Pharo-dev] [Ann] ReadWriteLock

Yes. When process suspend called during termination process has no more semaphore as suspendingList 2016-01-08 14:56 GMT+01:00 Henrik Johansen : > Ugh, there's a bug with the Processor activeProcess suspendingList, I only > checked in the case where it *should*

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 08 Jan 2016, at 3:24 , Denis Kudriashov wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen >: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be

Re: [Pharo-dev] [Ann] ReadWriteLock

Ugh, there's a bug with the Processor activeProcess suspendingList, I only checked in the case where it *should* signal. Take it as an inspiration :) Cheers, Henry > On 08 Jan 2016, at 2:40 , Henrik Johansen > wrote: > > Here's an alternative implementation,

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-08 15:17 GMT+01:00 Henrik Johansen : > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the > process actually on the list... > I just test it in workspace. sema := Semaphore

Re: [Pharo-dev] [Ann] ReadWriteLock

Long standing Case 5959 "Process suspension and Semaphore clash" seems related... https://pharo.fogbugz.com/default.asp?5959 cheers -ben On Fri, Jan 8, 2016 at 10:45 PM, Denis Kudriashov wrote: > I not understand. Is you code is working for you? > > This test return nil on

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-07 0:15 GMT+01:00 Ben Coman : > > I'm not qualified to judge, but is sounds okay. I have an alternative > proposal to consider that hopefully might remove Semaphore handling > completely from Process>>terminate. > > What if we have a wait primitive that instead of

Re: [Pharo-dev] [Ann] ReadWriteLock

If you run it, and are confused '2 start' never shows up in transcript, I intended the start messages to be outside critical blocks, sorry for old copypasta. Cheers, Henry > On 06 Jan 2016, at 1:29 , Henrik Johansen > wrote: > >> >> On 05 Jan 2016, at 7:52 ,

Re: [Pharo-dev] [Ann] ReadWriteLock

Ok. I wrote MutextTests which show problems. See in attachment. Attached Mutex.st contains fix which suggest Ben for his scenario. But it broke other scenario. Mutex>>critical: aBlock "Evaluate aBlock protected by the receiver." | activeProcess signalRequired blockValue | activeProcess :=

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-06 14:32 GMT+01:00 Denis Kudriashov : > Ok. I wrote MutextTests which show problems. See in attachment. > Attached Mutex.st contains fix which suggest Ben for his scenario. But it > broke other scenario. > > Mutex>>critical: aBlock > "Evaluate aBlock protected by the

Re: [Pharo-dev] [Ann] ReadWriteLock

I publish slice with MutexTest. So future changes around all this will be verified by CI 2016-01-06 14:32 GMT+01:00 Denis Kudriashov : > Ok. I wrote MutextTests which show problems. See in attachment. > Attached Mutex.st contains fix which suggest Ben for his scenario. But

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 05 Jan 2016, at 7:52 , Henrik Johansen > wrote: > > >> On 05 Jan 2016, at 7:24 , Denis Kudriashov > > wrote: >> >> >> 2016-01-05 18:49 GMT+01:00 Henrik Johansen >

Re: [Pharo-dev] [Ann] ReadWriteLock

I realize that current approach to handle situation in the #terminate method is the only way. But we need to generalize it somehow and make more explicit. It should be visible inside method which required such logic (like current Semaphore>>critical:). You suggest something like culling unwind

Re: [Pharo-dev] [Ann] ReadWriteLock

On Thu, Jan 7, 2016 at 1:48 AM, Denis Kudriashov wrote: > I realize that current approach to handle situation in the #terminate method > is the only way. > But we need to generalize it somehow and make more explicit. It should be > visible inside method which required such

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi. 2016-01-04 19:19 GMT+01:00 Igor Stasenko : > It heavily depends on data structure you using what kind of > synchronization mechanism is more efficient than another. > For instance AtomicQueue implementation is one that falls in such category > 'many readers, but only

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-04 18:51 GMT+01:00 Tudor Girba : > Is this meant to be part of the main distribution? I don't know. People should decide it. To me it is normal to get explicit dependency in configuration.

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi 2016-01-04 18:55 GMT+01:00 Max Leske : > Hi Denis, > > How does your ReadWriteLock compare to Monitor? I was under the impression > that what you describe could be done with a Monitor. Monitor is different synchronisation mechanism. It can be used to implement

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 05 Jan 2016, at 5:10 , Denis Kudriashov wrote: > > > 2016-01-05 16:54 GMT+01:00 Denis Kudriashov >: > 2016-01-05 16:06 GMT+01:00 Ben Coman >: > This is really

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-05 17:25 GMT+01:00 Denis Kudriashov : > Comment inside #critical: method said that we should signal in any case. I think I not correctly understand this point when read it. Process terminating case is not mention in comment.

Re: [Pharo-dev] [Ann] ReadWriteLock

I found problem. Look at Process>>terminate. There is special place: "Figure out if we are terminating the process while waiting in > Semaphore>>critical: > In this case, pop the suspendedContext so that we leave the ensure: block > inside > Semaphore>>critical: without signaling the semaphore."

Re: [Pharo-dev] [Ann] ReadWriteLock

On Tue, Jan 5, 2016 at 11:59 PM, Denis Kudriashov wrote: > > 2016-01-05 16:06 GMT+01:00 Ben Coman : >> >> btw I have this growing suspicion that we should eliminate >> Semaphore>>critical: and Semaphore>>forMutualExclusion. Semaphores >> on their own

Re: [Pharo-dev] [Ann] ReadWriteLock

On Wed, Jan 6, 2016 at 12:30 AM, Henrik Johansen wrote: > > On 05 Jan 2016, at 5:10 , Denis Kudriashov wrote: > > > 2016-01-05 16:54 GMT+01:00 Denis Kudriashov : >> >> 2016-01-05 16:06 GMT+01:00 Ben Coman

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-05 16:54 GMT+01:00 Denis Kudriashov : > 2016-01-05 16:06 GMT+01:00 Ben Coman : > >> 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

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 05 Jan 2016, at 5:25 , Denis Kudriashov wrote: > > I found problem. Look at Process>>terminate. There is special place: > > "Figure out if we are terminating the process while waiting in > Semaphore>>critical: > In this case, pop the

Re: [Pharo-dev] [Ann] ReadWriteLock

On Tue, Jan 5, 2016 at 1:39 AM, Denis Kudriashov wrote: > Hi. > > I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > > Gofer it > smalltalkhubUser: 'Pharo' project: 'ReadWriteLock'; > configurationOf: 'ReadWriteLock'; >

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-05 16:06 GMT+01:00 Ben Coman : > 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

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi Thank you very much for this analysts. 2016-01-05 16:06 GMT+01:00 Ben Coman : > 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

Re: [Pharo-dev] [Ann] ReadWriteLock

This code looks quite bad to me. Le 5/1/16 17:25, Denis Kudriashov a écrit : I found problem. Look at Process>>terminate. There is special place: "Figure out if we are terminating the process while waiting in Semaphore>>critical: In this case, pop the suspendedContext so that we

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-05 18:49 GMT+01:00 Henrik Johansen : > ifCurtailed: only unwinds if an error/termination occured, so that would > mean not signalling the semaphore when everything goes as planned, and we > leave the critical section... I not suppose to replace #ensure:

Re: [Pharo-dev] [Ann] ReadWriteLock

> On 05 Jan 2016, at 7:24 , Denis Kudriashov wrote: > > > 2016-01-05 18:49 GMT+01:00 Henrik Johansen >: > ifCurtailed: only unwinds if an error/termination occured, so that would mean > not signalling

Re: [Pharo-dev] [Ann] ReadWriteLock

2016-01-05 18:15 GMT+01:00 Ben Coman : > But Semaphore>>forMutualExclusion *encourages* people to believe > semaphores can be used *on*their*own* for mutual exclusion, when they > *shouldn't*. You *must* add ownership. If the mutual exclusion > object doesn’t have

Re: [Pharo-dev] [Ann] ReadWriteLock

Ben would you not be interested to write a little chapter on concurrency because we would all benefit from it. I can help but I'm pretty bad with concurrency. I'm sure that doing that we will find a lot of things to improve in Pharo :) Stef Le 5/1/16 18:15, Ben Coman a écrit : On Tue, Jan

Re: [Pharo-dev] [Ann] ReadWriteLock

Thanks! Doru > On Jan 6, 2016, at 12:56 AM, Ben Coman wrote: > > okay. I'll have a go. > cheers -ben > > On Wed, Jan 6, 2016 at 3:28 AM, stepharo wrote: >> Ben >> >> would you not be interested to write a little chapter on concurrency because >> we

Re: [Pharo-dev] [Ann] ReadWriteLock

okay. I'll have a go. cheers -ben On Wed, Jan 6, 2016 at 3:28 AM, stepharo wrote: > Ben > > would you not be interested to write a little chapter on concurrency because > we would all benefit from it. > I can help but I'm pretty bad with concurrency. > I'm sure that doing that

[Pharo-dev] [Ann] ReadWriteLock

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

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi, If I understand correctly: - the Monitor only offer one kind of critical section that typically affects everyone equally, - while with the new ReadWriteLock, the readers will be blocked only if a writer will acquire the writer critical section. Cheers, Doru > On Jan 4, 2016, at 7:55 PM,

Re: [Pharo-dev] [Ann] ReadWriteLock

Quite elegant! :) Is this meant to be part of the main distribution? Doru > On Jan 4, 2016, at 7:39 PM, Denis Kudriashov wrote: > > Hi. > > I implemented small package ReadWriteLock > http://smalltalkhub.com/mc/Pharo/ReadWriteLock/main. > > Gofer it >

Re: [Pharo-dev] [Ann] ReadWriteLock

Hi Denis, How does your ReadWriteLock compare to Monitor? I was under the impression that what you describe could be done with a Monitor. Cheers, Max > On 04 Jan 2016, at 18:39, Denis Kudriashov wrote: > > Hi. > > I implemented small package ReadWriteLock >

Re: [Pharo-dev] [Ann] ReadWriteLock

It heavily depends on data structure you using what kind of synchronization mechanism is more efficient than another. For instance AtomicQueue implementation is one that falls in such category 'many readers, but only single writer'. But it's not using semaphores to synchronise access to it. On 4