Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ruby > #7074

Re: multithreading best practice

Show all headers | View raw

Good evening,

On Sun, 11 Jan 2015 16:36:37 +0000 (UTC),
Doc O'Leary <droleary@2usenet2014.subsume.com> wrote:
> For your reference, records indicate that 
> Michael Uplawski <michael.uplawski@uplawski.eu> wrote:
>
>> Let's assume, the current file-size *had to be protected* by a Mutex,
>> because two threads try at some time or other to alter its value.
>
> There is no reason to do this in the scenario you describe. 

Yes, I know. ;-) But as there is not much benefit to be expected from
multithreading in my current ... programming-tasks, they are more
exciting than useful, a source of inspiration... I permit myself some
“extravagance”, as programming stuff for no reason whatsoever was a
dream, when I had to do it for money.

> The only
> thread that should have need to alter the size value is the one doing
> the actual downloading.  The thread that displays progress should have
> no reason to do anything other than read the value, and there isn’t
> really any overwhelming need for it to be byte-accurate

:-) Right. I removed the Mutex for this reason. It was dumb to
use one in the first place, like an automatism, when thread, mutex,
semaphore, critical sections and shared memory suddenly crossed my mind
and all at once. I had to empty the attic of our house in renovation,
when David Butenhof fell from the shelf. 

> Not having any code to look at, my guess is that your main issue is
> that the design of the code wasn’t sufficiently isolated to work well
> in a multi-threaded environment.

Right again. But succeeding in this way and arriving at a working
program anyway, is just hilarious... No, the code does not support my
claims nor currently document my lack of knowledge with threads. You can
deplore that my scenario is too hypothetical.

> Yes, you can add in a ton of Mutex
> locks to address it, but the better solution is take a step back and
> refactor the code to better fit a concurrent design.

I found Robert Klemme's advice quite useful and worth some
experimenting. But I am fine with your advice, too. At least there is
some confirmation.

Have a good week, all.

Michael

P.S.: For a laugh or two, here is the “program” (work in progress):
gem install get_mp3


-- 
GnuPG/OpenPGP  4096R/3216CF02 2013-11-15 [expires: 2015-11-15]
sub   4096R/2751C550 2013-11-15 [expires: 2015-11-15]

Back to comp.lang.ruby | Previous | Next — Previous in thread | Find similar

Thread

Re: multithreading best practice Doc O'Leary  <droleary@2usenet2014.subsume.com> - 2015-01-11 16:36 +0000
  Re: multithreading best practice Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-11 19:42 +0100

csiph-web