Porable Semaphore implemented in C++ ?

[Steven Woody]

Hi,

i am writting some classes, those need to work in both linux and
windows. in my problem, there are mutiple productor and one
consumer, productors each in a different thread are trying to append a
byte to a shared buffer while the consumer in the main thread will
remove one byte every some milliseconds.

the productors has to wait if the buffer is read/write by other
productors or the consumer, on the other hand, the consumer should
immediately exit if the buffer is read/write by any productor.

i am thinking, for the problem above, the semaphore can help. is
there a portable semaphore implementation in C++ ( if not, in C )?

thanks in advance.

-
woody

 

[Zeppe]

Hi,

i am writting some classes, those need to work in both linux and
windows. in my problem, there are mutiple productor and one
consumer, productors each in a different thread are trying to append a
byte to a shared buffer while the consumer in the main thread will
remove one byte every some milliseconds.

the productors has to wait if the buffer is read/write by other
productors or the consumer, on the other hand, the consumer should
immediately exit if the buffer is read/write by any productor.

i am thinking, for the problem above, the semaphore can help. is
there a portable semaphore implementation in C++ ( if not, in C )?

thanks in advance.

A good idea in my opinion would be to look for the boost thread library.
It's not standard, but it's portable enough. It hasn't got semaphores,
though. However, I think a mutex solution can be devised easily and it
may be less error-prone.

Regards,

Zeppe

 

[Steven Woody]

A good idea in my opinion would be to look for the boost thread library.
It's not standard, but it's portable enough. It hasn't got semaphores,
though. However, I think a mutex solution can be devised easily and it
may be less error-prone.

Regards,

Zeppe

ok, i go to study it. but i have one thing in doubt: semaphores or
other mutex solutions should have to dependent on some sort of 'atomic
operation' which should be OS-dependent, am i right? so how can a
library implement it without depends on OS?

ps. how to implement atomic oepration in Linux and how to implement it
in Windows? thanks.

 

[anon]

ok, i go to study it. but i have one thing in doubt: semaphores or
other mutex solutions should have to dependent on some sort of 'atomic
operation' which should be OS-dependent, am i right? so how can a
library implement it without depends on OS?

Yes, it is OS-dependent, and a library can implement it with
#ifdef something
// implementation for window
#else
// implementation for linux
#endif

ps. how to implement atomic oepration in Linux and how to implement it
in Windows? thanks.

You are better asking those questions in another news group. Maybe
comp.programming.threads

 

[James Kanze]

ok, i go to study it. but i have one thing in doubt:
semaphores or other mutex solutions should have to dependent
on some sort of 'atomic operation' which should be
OS-dependent, am i right? so how can a library implement it
without depends on OS?

The library implementation isn't necessarily "portable"; they
have a separate implementation for Windows and for Posix threads
(and don't support anything else, as far as I know). The whole
point being that by using such a library, that becomes their
problem, not yours. (How you open and write to a file also
depends on the system. But if you use std:fstream, that's
someone else's problem, too.)

ps. how to implement atomic operation in Linux and how to
implement it in Windows? thanks.

In both cases, you have Mutex (called CriticalSection under
Windows, I think). That's not always sufficient, of course, so
boost::threads also provide conditions, modeled on Posix
conditions; I don't know how they implement this under Windows,
but they do (and so I don't have to).

Lockfree algorithms also exist for your specific problem, I
think, but they require special machine instructions to ensure
that the modifications in one thread are visible in the same
order in other threads. Which means that you cannot implement
them in standard C++.

 

[Ole Nielsby]

Yes, it is OS-dependent, and a library can implement it with
#ifdef something
// implementation for window
#else
// implementation for linux
#endif

The Juce framework http://www.rawmaterialsoftware.com/juce/ has
some thread stuff that might prove helpful...

 

[Scott Gifford]

[...]

Lockfree algorithms also exist for your specific problem, I
think, but they require special machine instructions to ensure
that the modifications in one thread are visible in the same
order in other threads. Which means that you cannot implement
them in standard C++.

Intel's Thread Building Blocks provide a portable lock-free queue and
portable atomic variables:

http://osstbb.intel.com/

I believe currently it's portable across OS's, but works only for
x86-compatible processors. It appear to be written in a generic
enough way that it could be ported to other architectures if they
support atomic test-and-set, though.

But I had no trouble implementing a very simple shared queue with
pretty good performance using Boost mutexes and condition variables
around an STL queue.

----Scott.

 

[Steven Woody]

[...]

Lockfree algorithms also exist for your specific problem, I
think, but they require special machine instructions to ensure
that the modifications in one thread are visible in the same
order in other threads. Which means that you cannot implement
them in standard C++.

Intel's Thread Building Blocks provide a portable lock-free queue and
portable atomic variables:

http://osstbb.intel.com/

I believe currently it's portable across OS's, but works only for
x86-compatible processors. It appear to be written in a generic
enough way that it could be ported to other architectures if they
support atomic test-and-set, though.

But I had no trouble implementing a very simple shared queue with
pretty good performance using Boost mutexes and condition variables
around an STL queue.

----Scott.

thanks, i decide to study Boost.thread. i just don't know if it is
hard to learn. i don't get many days left

 

[Scott Gifford]

[...]

thanks, i decide to study Boost.thread. i just don't know if it is
hard to learn. i don't get many days left

I found it very straightforward. This article was helpful in getting
started:

http://www.ddj.com/cpp/184401518

---Scott.