Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

OT: Locking and syncing mechanisms available on *nix.

by BrowserUk (Pope)
on Mar 27, 2011 at 08:09 UTC ( #895735=perlquestion: print w/ replies, xml ) Need Help??
BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

On windows, I have a whole range of these mechanisms available, each of which lends itself to certain uses better than others.

The only mechanism I'm aware of for use with pthreads on *nix are condition variables. There must be others: What are they are? Where can I read about them?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on OT: Locking and syncing mechanisms available on *nix.
Re: OT: Locking and syncing mechanisms available on *nix.
by nikosv (Hermit) on Mar 27, 2011 at 09:04 UTC
    there are mutexes as well

    On windows, I have a whole range of these mechanisms available

    also if you look at a higher level there is the SynchronizationContext

      Sorry. I misread your post. Due to the formatting, I read your response as there are mutexes as well On windows,.

      Also, I'm not sure what use the second link was?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Also, I'm not sure what use the second link was?

        It's what is behind the BackgroundWorker component.

        I've posted it here just for informational purposes,looking at an alternative concept-wise,since it is releated to windows and threading
Re: OT: Locking and syncing mechanisms available on *nix.
by sundialsvc4 (Monsignor) on Mar 27, 2011 at 16:04 UTC

    Whew!   I’m losing track of this thread, trying to read through all the nesting.   Would it be possible to start another “level-one” response to this thread that re-states the problem as its definition has become refined so-far?   It is clear that a refinement of the question has taken place, but not quite so clear just what it has refined into.   Many thanks in advance.

Re: OT: Locking and syncing mechanisms available on *nix.
by Illuminatus (Curate) on Mar 27, 2011 at 18:31 UTC
    *nix pthreads really only provides condition variables and mutexs as thread-level mechanisms for safeguarding concurrency. At the system level, *nix typically provides semaphores, which can be a kind of combination of these (ie counting semaphores can be used to mimick similar behavior to condition variables). Semaphores are also system wide, and can be used to sync access to things beyond process scope (shared-mem, files, etc) I think you are misinformed about the performance of mutexes and condition vars. Both are quite fast, and do not, by default, involve polling. Even semaphores have very limited performance implications. here is what I consider to be a good description on the use of condition variables, and why mutexes are also necessary.

    I work on a tcp-proxy system where performance is at a premium (on Linux), and the mutex/cond-wait mechanism is never even a blip when when we profile it looking for bottlenecks.

    fnord

      and why mutexes are also necessary.

      Sorry, but that example is contrived to need a mutex. The signalling condition uses a global variable: Lock associated mutex and check value of a global variable.

      Now consider the case of a signalling condition that doesn't involve a global variable. Then what use is the mutex?

      As for the performance characteristics of mutexes. If I am misinformed, then so is half of the internet it seems.

      With regard to your TCP/IP example. It is understandable that mutexes are not a bottleneck where IO is involved. Even the 300 to 400 cycles that it takes to make a ring3 - ring0 - ring3 transition pale when compared to IO waits.

      But user-space only, atomic instructions, even with barrier instructions are much faster for memory to memory operations.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Well, I can't speak for Windows (which, I gather from your posts over time you are an expert in), but for Linux, I believe you are going to find the scheduler manipulation is going to be more overhead than the signaling you choose. If you really only want a thread to get to a certain point, and then wait until it is told to continue, then you can use suspend/continue. The first thread can call pthread_suspend on itself, which will take it off the run queue (so it no longer takes any CPU). Then the second thread can use pthread_continue to 'signal' it to continue. Your only overhead will be manipulation of the queues in the scheduler, which will have to happen regardless of your mechanism.

        fnord

Re: OT: Locking and syncing mechanisms available on *nix.
by sundialsvc4 (Monsignor) on Mar 28, 2011 at 03:14 UTC

    My gut feeling on this one, BrowserUK, is that you may just be stuck with what Unix/Linux does have to offer.

    As the Wine implementation team observed (they’ve created a fairly-complete Win32 emulation layer for Linux; see http://www.winehq.org), the Win32 API is much more rich and expressive in this area than the one available in Unix and Linux.   (What they came up with is a rather-awful implementation using a wineserver process and sockets.)   In making this statement, I am not passing any judgment.   This is likely to be one of those situations where “you gotta dance with the one that brung ya,” and diplomatically pretend that it doesn’t smell quite as bad as it actually does.   If a mutex is needed in a case where both taste and reason insist that it should not be so, well, “c’est la guerre, n’est ce pas?”

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://895735]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-08-22 21:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (165 votes), past polls