Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: sf::Thread::GetThreadID + Wait Events  (Read 2476 times)

0 Members and 1 Guest are viewing this topic.

Disch

  • Full Member
  • ***
  • Posts: 220
    • View Profile
sf::Thread::GetThreadID + Wait Events
« on: July 16, 2011, 04:15:46 am »
I'm a little surprised that sf::Thread doesn't have static GetThreadID or similar function which returns a thread-unique identifier for the current thread.

Can we get this added?


EDIT:

Also WinAPI has a threading feature that I just realized I need if I want to implement this thing I have in mind.

WinAPI has these "Event Objects" which are used for inter-thread communication.  The idea is, the event has a boolean state (set or unset).  Threads can then "wait" for the event until it has been set.

As soon as the event has been set, all threads waiting for it are resumed.

Any thread can set/unset the event state.

Of course, since SFML uses "Event" for something completely different, it would have to be renamed.  But I think it would be a great addition.

EDIT2:  More reading:

http://msdn.microsoft.com/en-us/library/ms686915%28v=VS.85%29.aspx

Disch

  • Full Member
  • ***
  • Posts: 220
    • View Profile
sf::Thread::GetThreadID + Wait Events
« Reply #1 on: July 16, 2011, 06:46:09 am »
FWIW, I was able to simulate the event idea with just basic threads and mutexes.  A native implementation would be better, though, as the below approach involves creating an entirely separate thread, and has additional latency due to sleeping:

Code: [Select]

class ThreadEvent : public sf::NonCopyable
{
public:
    ThreadEvent()
        : mThread(&ThreadEvent::ThreadLogic,this)
        , mState(state_none)
        , mWantExit(false)
        , mIsLocked(false)
    {
        mThread.Launch();
    }

    ~ThreadEvent()
    {
        mWantExit = true;
        mThread.Wait();
    }

    inline bool IsLocked()  {   return mIsLocked;                   }
    inline void Lock()      {   ChangeState( state_wantlock );      }
    inline void Unlock()    {   ChangeState( state_wantunlock );    }

    inline void Wait()      {   mStateLock.Lock(); mStateLock.Unlock(); }

private:
    void ThreadLogic()
    {
        while(!mWantExit)
        {
            if(mState == state_wantlock)
            {
                if(!mIsLocked)
                {
                    mStateLock.Lock();
                    mIsLocked = true;
                }
                mState = state_none;
            }
            if(mState == state_wantunlock)
            {
                if(mIsLocked)
                {
                    mStateLock.Unlock();
                    mIsLocked = false;
                }
                mState = state_none;
            }
            try{
            sf::Sleep(1);
            }catch(...){}
        }

        if(mIsLocked)
            mStateLock.Unlock();
    }

    sf::Thread      mThread;
    sf::Mutex       mStateLock;     // locked by mThread when state is "reset"
    sf::Mutex       mStateChange;   // locked to guard state changes

    enum state_t
    {
        state_none,
        state_wantlock,
        state_wantunlock
    };
    volatile state_t    mState;
    volatile bool       mIsLocked;
    volatile bool       mWantExit;

   
    void     ChangeState(state_t newstate)
    {
        sf::Lock lock(mStateChange);
        mState = newstate;
        while(mState != state_none)
            sf::Sleep(1);
    }
};

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
sf::Thread::GetThreadID + Wait Events
« Reply #2 on: July 16, 2011, 09:55:32 am »
Quote
I'm a little surprised that sf::Thread doesn't have static GetThreadID or similar function which returns a thread-unique identifier for the current thread.

What for?

Quote
WinAPI has these "Event Objects" which are used for inter-thread communication.

The generic name for this feature is "wait condition". Ceylo implemented a portable version of them for his sfe::Movie project (in case you're interested).
It's true that it's a useful feature, but SFML was never meant to be a complete threading library, it only implements what it needs. If I go this way, there are several other things to add: atomic variables/operations, semaphores, spin locks, ...
The next C++ standard will include all this stuff so it's probably not relevant to add it to SFML.
Laurent Gomila - SFML developer

 

anything